| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com> |
| Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: "stuck spinlock" |
| Date: | 2013-12-13 17:28:56 |
| Message-ID: | 24744.1386955736@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Christophe Pettus <xof(at)thebuild(dot)com> writes:
> On Dec 13, 2013, at 8:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 was experiencing 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-12-13 17:34:02 | Re: "stuck spinlock" |
| Previous Message | Tom Lane | 2013-12-13 17:19:56 | Re: "stuck spinlock" |