Re: beta5 ...
От | Bruce Momjian |
---|---|
Тема | Re: beta5 ... |
Дата | |
Msg-id | 200102170218.VAA21798@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: beta5 ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: