On 2013-11-30 11:40:36 -0500, Noah Misch wrote: > On Sat, Nov 30, 2013 at 05:22:04PM +0100, Andres Freund wrote: > > On that front: I'd love for somebody else to look at the revised 9.3 > > freezing logic. > > Do you speak of the changes to xmax freezing arising from the FK lock > optimization?
Yes. There had been several major bugs in 9.3+ around freezing: * old "updater" xids in multixacts haven't been subjected to the new xmin horizon => inaccessible or duplicated rows. * If a multi was too old, we simply removed it, even if it contained an committed xmax => duplicate rows * If HEAP_XMAX_INVALID was set in heap_freeze_tuple() and heap_tuple_needs_freeze() we didn't do anything about xmax. That's completely not okay since the hint bit might not have been set on the standby => diverging standby and primary, with unfrozen rows remaining on the standby, missing or duplicate rows there. The fixed (2393c7d102368717283d7121a6ea8164e902b011) heap_freeze_tuple() and heap_tuple_needs_freeze() look much safer to me, but theres lots of complexity there. I don't see any alternative to the complexity until we change the format of xl_heap_freeze, but some more eyes than Alvaro's and mine definitely would be good. 71ad5a8475b4df896a7baa71e6dd3c455eebae99 also touches quite some intricate code paths and fixes a good amount of bugs, so it's definitely also worthy of further inspection. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
