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'scompletely not okay since the hint bit might not have been set on the standby => diverging standby and primary,
withunfrozen 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
