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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
