Re: Btree runtime recovery. Stuck spins.
От | Tom Lane |
---|---|
Тема | Re: Btree runtime recovery. Stuck spins. |
Дата | |
Msg-id | 20532.981743015@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Btree runtime recovery. Stuck spins. (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Btree runtime recovery. Stuck spins.
|
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Our spinlocks don't go into an infinite test loop, right? They back off > and retest at random intervals. Not very random --- either 0 or 10 milliseconds. (I think there was some discussion of changing that, but it died off without agreeing on anything.) The point though is that the code is tuned for use with spinlocks protecting shared-memory data structures, where no one is supposed to be holding the lock for long; so a short retry delay is appropriate, and we don't need a very long time before declaring "stuck spinlock" either. This is not optimal for cases where someone may be holding the lock for a good while, but detuning the code so that it works less well for the shmem-structure case isn't the answer. We need two different mechanisms. regards, tom lane
В списке pgsql-hackers по дате отправления: