Re: Nested transactions: low level stuff

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)