Re: pgsql: Fix a couple of bugs in MultiXactId freezing

Noah Misch wrote:

> > On 2013-12-03 10:29:54 -0500, Noah Misch wrote:
> > > Sorry, my original report was rather terse.  I speak of the scenario exercised
> > > by the second permutation in that isolationtester spec.  The multixact is
> > > later than VACUUM's cutoff_multi, so 9.3.1 does not freeze it at all.  9.3.2
> > > does freeze it to InvalidTransactionId per the code I cited in my first
> > > response on this thread, which wrongly removes a key lock.
> > 
> > That one is clear, I was only confused about the Assert() you
> > reported. But I think I've explained that elsewhere.
> > 
> > I currently don't see fixing the errorneous freezing of lockers (not the
> > updater though) without changing the wal format or synchronously waiting
> > for all lockers to end. Which both see like a no-go?
> 
> Not fixing it at all is the real no-go.  We'd take both of those undesirables
> before just tolerating the lost locks in 9.3.

Well, unless I misunderstand, this is only a problem in the case that
cutoff_multi is not yet past but cutoff_xid is; and that there are
locker transactions still running.  So it's really a corner case.  Not
saying it's impossible to hit, mind.

> The attached patch illustrates the approach I was describing earlier.  It
> fixes the test case discussed above.  I haven't verified that everything else
> in the system is ready for it, so this is just for illustration purposes.

Wow, this is scary.  I don't oppose it in principle, but we'd better go
over the whole thing once more to ensure every place that cares is
prepared to deal with this.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services