Heikki Linnakangas wrote: > BRIN update is not quite right, however. brin_getinsertbuffer() can > initialize a page, but the caller might bail out without using the page and > WAL-logging the change. If that happens, the next update that uses the same > page will WAL-log the change but it will not use the XLOG_BRIN_INIT_PAGE > option, and redo will not initialize the page. Redo will fail.
There's even a worse case. In brin_getinsertbuffer, if an old buffer is passed, and the function extends the index, and then brin_getinsertbuffer finds that the old buffer has been used to extend the revmap, then we don't even return the newly extended page. We do enter it into the FSM, though, and the FSM is vacuumed. So next time around somebody requests a page from FSM, it might return that page; but since it wasn't initialized, the insertion will fail. Everybody expects the page to have been initialized previously, but this will not be the case here. I guess that function needs some restructuring, but it's pretty hairy already ... -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
