> However, there's still a problem: GetUndoRecPtr also gets SInvalLock
> while its caller holds WALInsertLock, and therefore this routine
> could create the second leg of the deadlock too.  Removing the
> SInvalLock lock there creates the problem that backends might be
> added to or deleted from the PROC array while GetUndoRecPtr runs.
> I think it might be possible to survive that, by adding an assumption
> that logRec.xrecoff can be set to zero atomically, but it 
> seems tricky.

Checkpoint' undo is not used currently so just comment out GetUndoRecPtr
call in CreateCheckPoint - we'll find solution later.

Vadim

Tue, 18 Dec 2001 10:55:41 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
Re: Deadlock condition in current sources
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> Checkpoint' undo is not used currently so just comment out GetUndoRecPtr
> call in CreateCheckPoint - we'll find solution later.

I thought about that, but figured you'd object ;-)

One possibility is to do something you had recommended awhile back for
other reasons: add a spinlock to each PROC structure and use the
spinlock, rather than SInvalLock, to protect setting and reading of
xmin, logRec, and related fields.  I haven't finished working out all
the details, though, and this seems like a rather large change to make
at this late stage of beta.  Comments?

			regards, tom lane

Tue, 18 Dec 2001 14:05:43 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Deadlock condition in current sources 