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
