I am GO.  SET DIAGNOSTICS is my only open item left.


> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > things appear to have quieted off nicely ... so would like to put out a
> > Beta5 for testing ...
> 
> > Tom, I saw/read your proposal about the JOIN syntax, but haven't seen any
> > commit on it yet, nor any arguments against the changes ... so just
> > wondering where those stand right now?
> 
> You must have been looking the other way ;-) ... it's committed.
> 
> What I'm currently thinking about is the discussion from last week where
> Vadim reported that he could get "stuck spinlock" errors during btree
> index crash recovery, because the backend fixing the index might hold
> disk-buffer locks longer than the ~70 second timeout for spinlocks
> (see "Btree runtime recovery. Stuck spins" thread on 2/8 and 2/9).
> 
> Vadim says (and I agree) that we really ought to implement a new
> lightweight lock manager that would fall between spinlocks and regular
> locks in terms of overhead and functionality.  But it's not reasonable
> to try to do that for 7.1 at this late date.  So I was trying to pick a
> stopgap solution for 7.1.  Unfortunately Vadim's off to Siberia and I
> can't consult with him...
> 
> I'm currently thinking of modifying the buffer manager so that disk
> buffer spinlocks use an alternate version of s_lock() with no timeout,
> and perhaps longer sleeps (no zero-delay selects anyway).  This was one
> of the ideas we kicked around last week, and I think it's about the best
> we can do for now.  Comments anyone?
> 
> Other than that, I have nothing to hold up a beta5.  Anyone else?
> 
>                       regards, tom lane
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [EMAIL PROTECTED]               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Reply via email to