I am GO. SET DIAGNOSTICS is my only open item left.
> The Hermit Hacker <scrappy@hub.org> 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 pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026