Re: Re: [COMMITTERS] pgsql: Don't unblock SIGQUIT in the SIGQUIT handler This was possibly

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Re: [COMMITTERS] pgsql: Don't unblock SIGQUIT in the SIGQUIT handler This was possibly
Дата
Msg-id 1289425873.13614.1.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Don't unblock SIGQUIT in the SIGQUIT handler This was possibly  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On ons, 2010-11-10 at 20:30 +0900, Fujii Masao wrote:
> On Thu, Dec 17, 2009 at 8:05 AM, Peter Eisentraut <petere@postgresql.org> wrote:
> > Log Message:
> > -----------
> > Don't unblock SIGQUIT in the SIGQUIT handler
> >
> > This was possibly linked to a deadlock-like situation in glibc syslog code
> > invoked by the ereport call in quickdie().  In any case, a signal handler
> > should not unblock its own signal unless there is a specific reason to.
> >
> > Modified Files:
> > --------------
> >    pgsql/src/backend/tcop:
> >        postgres.c (r1.577 -> r1.578)
> >        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c?r1=1.577&r2=1.578)
> >    pgsql/src/include/libpq:
> >        pqsignal.h (r1.35 -> r1.36)
> >        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/pqsignal.h?r1=1.35&r2=1.36)
> 
> Why wasn't this patch backported? Recently my customer encountered
> the bug which this patch fixed, in 8.3.

It was at the time a perhaps experimental behavioral change.

I'm also running a 8.3 version with this patched in, though.




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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: renaming contrib. (was multi-platform, multi-locale regression tests)
Следующее
От: David Fetter
Дата:
Сообщение: Re: wCTE behaviour