Re: Btree runtime recovery. Stuck spins.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Btree runtime recovery. Stuck spins.
Дата
Msg-id 12891.981665329@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Btree runtime recovery. Stuck spins.  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Список pgsql-hackers
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> 2. During tests I've got stuck spin aborts couple of times.
> So I've increased S_MAX_BUSY, placed elog(NOTICE, "WOULD BE STUCK")
> for spins == 20001 in s_lock_sleep() and rerun tests.
> I've got *many* "WOULD BE STUCK" notices but no one abort.
> Does it explain why I tried to avoid spin stuck "detection" code
> in WAL? -:)
> Shouldn't we increase S_MAX_BUSY and use ERROR instead of FATAL?

No.  If you have delays exceeding a minute, or that are even a visible
fraction of a minute, then a spinlock is NOT the correct mechanism to be
using to wait ... because guess what, it's spinning, and consuming
processor time to no purpose.  You should be using a lock instead for
anything that involves more than a trivial amount of delay.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Re: Syslog and pg_options (for RPMs)
Следующее
От: "Dominic J. Eidson"
Дата:
Сообщение: Re: Syslog and pg_options (for RPMs)