Re: beta5 ...
От | Tom Lane |
---|---|
Тема | Re: beta5 ... |
Дата | |
Msg-id | 13768.982358266@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | beta5 ... (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: beta5 ...
Re: beta5 ... Re: beta5 ... |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: