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
