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

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