Thread

1. Re: Deadlock condition in current sources

   Vadim Mikheev <vmikheev@sectorbase.com> — 2001-12-18T18:55:41Z

   > 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
   
   

2. Re: Deadlock condition in current sources

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-18T19:05:43Z

   "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