Robert Haas <robertmh...@gmail.com> writes: > On Mon, Mar 17, 2014 at 10:54 AM, Heikki Linnakangas > <hlinnakan...@vmware.com> wrote: >> Heap and B-tree WAL records also rely on PageAddItem etc. to reconstruct the >> page, instead of making a physical copy of the modified parts. And >> _bt_restore_page even inserts the items physically in different order than >> the normal codepath does. So for good or bad, there is some precedence for >> this.
> Yikes. Yeah. I think it's arguably a bug that _bt_restore_page works like that, even though we've not been burnt up to now. >> The imminent danger I see is if we change the logic on how the items are >> divided into posting lists, and end up in a situation where a master server >> adds an item to a page, and it just fits, but with the compression logic the >> standby version has, it cannot make it fit. As an escape hatch for that, we >> could have the WAL replay code try the compression again, with a larger max. >> posting list size, if it doesn't fit at first. And/or always leave something >> like 10 bytes of free space on every data page to make up for small >> differences in the logic. > That scares the crap out of me. Likewise. Saving some WAL space is *not* worth this kind of risk. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers