On Thu, Mar 20, 2003 at 01:40:44AM -0500, Tom Lane wrote:
> 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.
Well, the only way to see if they are right or wrong is testing them. I
will be trying to completely understand the transaction/block states so
I can implement the needed state machinery for nested transaction; with
this we can play with locks and the rest of resources.
I think this transaction state game is the easiest part of nested
transactions.
> Also see LW locks, which have no such management infrastructure ...
You can't end a transaction holding one of those; failure to do so is a
programming error. The only way it is allowed is when elog(ERROR) is
called. For that I propose that held_lwlocks is replaced with
typedef struct held_lwlocks
{
TransactionId xid[MAX_SIMUL_LWLOCKS];
LWLockId lid[MAX_SIMUL_LWLOCKS];
int num_locks_held;
} held_lwlocks;
and LWReleaseAll() modified appropiately.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Nunca confiaré en un traidor. Ni siquiera si el traidor lo he creado yo"
(Barón Vladimir Harkonnen)
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
