Re: augmenting MultiXacts to improve foreign keys

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: augmenting MultiXacts to improve foreign keys
Date: 2011-08-09 19:10:37
Message-ID: 64B402D3-368C-48EE-AA4B-879F4004F3B2@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Aug9, 2011, at 19:01 , Alvaro Herrera wrote:
> This would also help us find a solution to the problem that an aborted
> subtransaction that updates or excl-locks a tuple causes an earlier
> shared lock to be forgotten. We would deal with this by marking the
> Xmax with a new MultiXact that includes both the lock and the update.
> This means that this MultiXact would have to be WAL-logged. I would
> leave that for a later patch, but I think it's good that there's a way
> to fix it.

Yeah, I pondered something similar in the past, but never got around to
figuring out the details.

This would also allow us to modify the behaviour of tuple locks under
isolation level REPEATABLE READ to throw a serialization error if the
row was locked by an invisible transaction. Doing so would allow us to
get rid of the strange re-checking logic that RI triggers must currently
use in REPEATABLE READ mode, and would thus make it possible to implement
custom RI triggers in PL/pgSQL.

I'll try to find some time to check how that fits in with the new
per-tuple lock levels you proposed.

best regards,
Florian Pflug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-08-09 19:41:00 Re: augmenting MultiXacts to improve foreign keys
Previous Message Brian Pitts 2011-08-09 18:52:25 Ignore lost+found when checking if a directory is empty