Re: "stuck spinlock" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "stuck spinlock"
Date
Msg-id 24744.1386955736@sss.pgh.pa.us
Whole thread Raw
In response to Re: "stuck spinlock"  (Christophe Pettus <xof@thebuild.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: "stuck spinlock"
Next
From: Andres Freund
Date:
Subject: Re: "stuck spinlock"