Heikki Linnakangas wrote: > Looking closer, heap vacuum does a similar thing, but there are two > mitigating factors that make it safe in practice, I think: > > 1. An empty heap page is all-zeroes except for the small page header in the > beginning of the page. For a torn page to matter, the page would need to be > torn in the header, but we rely elsewhere (control file) anyway that a > 512-byte sector update is atomic, so that shouldn't happen. Note that this > hinges on the fact that there is no special area on heap pages, so you > cannot rely on this for index pages. > > 2. The redo of the first insert/update on a heap page will always > re-initialize the page, even when full-page-writes are disabled. This is the > XLOG_HEAP_INIT_PAGE optimization. So it's not just an optimization, it's > required for correctness.
Hmm, I guess this is a case of an optimization hiding a bug :-( I mean, if we didn't have that, we would have noticed this a lot sooner, I imagine. > 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. Hmm, interesting. > BTW, shouldn't there be a step in BRIN vacuum that scans all the BRIN pages? > If an empty page is missing from the FSM for any reason, there's nothing to > add it there. Probably, yeah, makes sense. If you recall, the original design I proposed had a scan of the whole index (though for other reasons I am thankful we got rid of that). > This is all very subtle. No kidding ... -- Á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
