Skip site navigation (1) Skip section navigation (2)

Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: MauMau <maumau307(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
Date: 2013-01-30 15:54:12
Message-ID: 6845.1359561252@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-01-30 10:23:09 -0500, Tom Lane wrote:
>> Yeah, it's a known hazard that quickdie() operates like that.

> What about not translating those? The messages are static and all memory
> needed by postgres should be pre-allocated.

That would reduce our exposure slightly, but hardly to zero.  For
instance, if SIGQUIT happened in the midst of handling a regular error,
ErrorContext might be pretty full already, necessitating further malloc
requests.  I thought myself about suggesting that quickdie do something
to disable gettext(), but it doesn't seem like that would make it enough
safer to justify the loss of user-friendliness for non English speakers.

I think the conflict between "we don't want SIGQUIT to interrupt this"
and "we do want SIGQUIT to interrupt that" is pretty fundamental, and
there's probably not any bulletproof solution (or at least none that
would have reasonable development/maintenance cost).  If we had more
confidence that there were no major loops lacking CHECK_FOR_INTERRUPTS
calls, maybe the set-a-flag approach would be acceptable ... but I
sure don't have such confidence.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Jeff JanesDate: 2013-01-30 15:58:07
Subject: Re: autovacuum not prioritising for-wraparound tables
Previous:From: Andrew DunstanDate: 2013-01-30 15:44:23
Subject: Re: pg_dump --pretty-print-views

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group