Tom mentioned to me that if you deadlock in a subtransaction, you have
to release the locks of the subtransaction. That could be tricky.
---------------------------------------------------------------------------
Alvaro Herrera wrote:
> 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"
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073