Re: Incomplete freezing when truncating a relation during vacuum

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