Re: Nested transactions: low level stuff

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Why do you say lock management is a can of worms? Locks are released at
> xact end by means of LockReleaseAll(), and this doesn't release all the
> locks the backend holds: only the locks that have the same xid that the
> committing transaction has (the mechanism has to be corrected for xact
> abort though).

Well, I'm not sure about this. Is it okay to release a child xact's
locks when the child commits? Usually the point of holding a lock till
commit is to ensure that other xacts will see your change as committed
when they get in. But they won't see the child's work as committed if
its parent is still open. On the other hand, an aborted child's locks
had better get released (consider case where child is aborting to get
out of a deadlock condition). This needs careful thought.

There are indeed some first-cut provisions in the lock code for multiple
transactions owned by a backend, but it'd be dangerous to assume that
they are either correct or complete. The only case that's tested is for
VACUUM to hold a lock across two transactions --- and this lock will not
be held in the face of an error, so it's not an accurate representation
of nested xacts anyway.

Also see LW locks, which have no such management infrastructure ...

regards, tom lane