Jeff Janes <jeff.ja...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
