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
