Back in commit 249a899f7, we introduced an atexit callback that forced
backend process cleanup to occur if some random backend plugin
(I'm looking at you, plperl and plpython) executed exit(). While that
seemed like a great safety feature at the time, bug #9464
http://www.postgresql.org/message-id/flat/20140307005623.1918.22473@wrigleys.postgresql.org
shows that this can actually destabilize things rather than improve them.
The issue is that code that does fork() and then does an exit() in the
subprocess will run the backend's atexit callback, which is The Wrong
Thing since the parent backend is (probably) still running.
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid, from some parent
backend process whose elbow we should not joggle. Can anyone see a flaw
in that?
There's an interesting connection here to the existing coding rule that
child processes of the postmaster have to do on_exit_reset() immediately
after being forked to avoid running the postmaster's on_exit routines
unintentionally. We've not seen any reported breakdowns in that scheme,
but I wonder if we ought to handle it differently, seeing as how people
keep coming up with new randomness that they want to load into the
postmaster.
regards, tom lane
