Re: Btree runtime recovery. Stuck spins.

Поиск
Список
Период
Сортировка
От Vadim Mikheev
Тема Re: Btree runtime recovery. Stuck spins.
Дата
Msg-id 005f01c09244$341e3440$4a79583f@sectorbase.com
обсуждение исходный текст
Ответ на Btree runtime recovery. Stuck spins.  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Ответы Re: Btree runtime recovery. Stuck spins.
Список pgsql-hackers
> > 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.

"Amount of delay" depends on system load - something we can't control...

Btree uses spins to lock buffers (as all other access methods) and so
I could use only spins in new code. And though tree recovery locks buffers
for longer time than normal insert operations it's possible to get
"stuck" spins when using concurrent buffers locks *everywhere* under
heavy load (especially with WAL which requires holding buffer locks
for duration of logging).

So, probably we have to use some kind of light locks (without deadlock
detection) for buffers, in future.

Vadim




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

Предыдущее
От: Justin Clift
Дата:
Сообщение: SPI_exec - Trying to access SPI_tuptable - error of 'dereferencing pointer to incomplete type'
Следующее
От: ncm@zembu.com (Nathan Myers)
Дата:
Сообщение: Re: Syslog and pg_options (for RPMs)