Re: Heads-Up: multixact freezing bug

On 2013-11-28 16:28:53 +0100, Andres Freund wrote:
> My current thoughts are that we need to check whether any member of a
> multixact needs freezing. If we find one we do MultiXactIdIsRunning() &&
> MultiXactIdWait() if!InRecovery. That's pretty unlikely to be necessary,
> but afaics we cannot guarntee it is not.

> The big problem with that solution is that we need to do a
> GetMultiXactIdMembers() during crash recovery which is pretty damn
> ugly. But I *think*, and that's where I really would like some input,
> given the way multixact WAL logging works that should be safe.

Bashing my head against the wall some more I think there's a much better fix:

Instead of calculating the multixact cutoff xid by using the global
minimum of OldestMemberMXactId[] and OldestVisibleMXactId[] and then
subtracting vacuum_freeze_min_age compute it solely as the minimum of
OldestMemberMXactId[]. If we do that computation *after* doing the
GetOldestXmin() in vacuum_set_xid_limits() we can be sure no mxact above
the new mxact cutoff will contain a xid below the xid cutoff. This is so
since it would otherwise have been reported as running by
GetOldestXmin().
With that change we can leave heap_tuple_needs_freeze() and
heap_freeze_tuple() unchanged since using the mxact cutoff is
sufficient.

Now, one could argue that this is a pessimization since we'll freeze
more: I argue that reducing the overhead by not having multis in those
tuples well offsets that cost.

There's some details around when calling AtEOXact_MultiXact() and
similar to be worked out, but I think it's otherwise a sound principle.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services