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