Re: Nested transactions: low level stuff - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Nested transactions: low level stuff
Date
Msg-id 20030320062439.GA8917@dcc.uchile.cl
Whole thread Raw
In response to Re: Nested transactions: low level stuff  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Nested transactions: low level stuff  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Nested transactions: low level stuff  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 19, 2003 at 09:38:21PM -0500, Tom Lane wrote:
> Hiroshi Inoue <Inoue@tpf.co.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"


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Fix for error in autocommit off
Next
From: Bruce Momjian
Date:
Subject: Re: Nested transactions: low level stuff