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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
