Noah Misch wrote: > On Tue, Dec 03, 2013 at 04:08:23PM +0100, Andres Freund wrote:
> > > (For clarity, the other problem demonstrated by the test spec is also a > > > 9.3.2 > > > regression.) > > > > Yea, I just don't see why yet... Looking now. > > 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. Attached is a patch to fix it. It's a simple fix, really, but it reverts the delete-abort-savept test changes we did in 1ce150b7bb. (This is a more complete version of a patch I posted elsewhere in this thread as a reply to Tom.) I added a new isolation spec to test this specific case, and noticed something that seems curious to me when that test is run in REPEATABLE READ mode: when the UPDATE is aborted, the concurrent FOR UPDATE gets a "can't serialize due to concurrent update", but when the UPDATE is committed, FOR UPDATE works fine. Shouldn't it happen pretty much exactly the other way around? -- Á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
