Re: "stuck spinlock"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "stuck spinlock"
Дата
Msg-id 24744.1386955736@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "stuck spinlock"  (Christophe Pettus <xof@thebuild.com>)
Список pgsql-hackers
Christophe Pettus <xof@thebuild.com> writes:
> On Dec 13, 2013, at 8:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Please apply commit 478af9b79770da43a2d89fcc5872d09a2d8731f8 and see
>> if that doesn't fix it for you.

> Great, thanks.  Would the statement_timeout firing invoke this path?  (I'm wondering why this particular installation
wasexperiencing this.)
 

Yeah, the problem is that either statement_timeout or lock_timeout
could cause control to be taken away from code that thinks it's
straight-line code and so doesn't have provision for getting cleaned
up at transaction abort.  Spinlocks certainly fall in that category.
I'm afraid other weird failures are possible, though I'm not sure
what.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "stuck spinlock"
Следующее
От: Andres Freund
Дата:
Сообщение: Re: "stuck spinlock"