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