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 06:24:39 |
Message-ID: | 20030320062439.GA8917@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 19, 2003 at 09:38:21PM -0500, Tom Lane wrote:
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Sorry I have a basic question.
> > Was there any consensus we would introduce nested transactions
> > (or savepoints) in the way currently discussed ?
>
> I think we are a long way from saying we can or will actually do it.
> Error handling and resource management (eg locks) are a couple of other
> huge cans of worms that have yet to be opened.
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).
This is exactly what is needed for nested transactions: the ending
subtransaction should release the locks it has, but the parent
transaction should keep the ones it had.
What's more, there's provision in LockAcquire() (storage/lmgr/lock.c
line 602) for making possible that a backend holds a lock more than once
in different XIDs.
I know I'm missing something, but what is it?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No es bueno caminar con un hombre muerto"
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-03-20 06:27:55 | Re: Nested transactions: low level stuff |
Previous Message | Bruce Momjian | 2003-03-20 06:10:31 | Re: Fix for error in autocommit off |