From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Nested transactions: low level stuff |
Date: | 2003-03-20 18:02:15 |
Message-ID: | 20030320180215.GF3257@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-03-20 18:33:16 | Re: Faster NUMERIC implementation |
Previous Message | Michael Meskes | 2003-03-20 18:00:57 | Re: Faster NUMERIC implementation |