Re: Archiver not exiting upon crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Archiver not exiting upon crash
Date: 2012-05-25 19:10:12
Message-ID: 27433.1337973012@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> So my test harness is an inexplicably effective show-case for the
> vulnerability, but it is not the reason the vulnerability should be
> fixed.

I spent a bit of time looking into this. In principle the postmaster
could be fixed to repeat the SIGQUIT signal every second or so, but
it would be a rather considerable wart on code that's already
overcomplicated for my taste (given that bugs in the postmaster are
basically game over). An example of the problems is that the
postmaster's own SIGQUIT signal handler presently just sends out the
child signals and calls exit(). We'd need some new "waiting for
children to die" state to allow for retransmission in such cases.
As far as the postmaster is concerned, it would be a lot better if
SIGQUIT could be considered reliable.

This leads me to the thought that maybe we have to deprecate use of
system() in Postgres backend code. If we simply fork and exec without
touching the signal handling, ISTM that would do what we want, and the
amount of added code would be pretty minimal (a lot less than would have
to be added to the postmaster to address this the other way). However,
I'm not too sure what would be required to make it go on Windows.
Comments? Does the Windows emulation of system() even have this issue
to begin with?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-25 20:02:50 Re: pg_dump and thousands of schemas
Previous Message Andrew Dunstan 2012-05-25 18:21:59 Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more