I had an idea about how to possibly solve the pg_terminate_backend
issue.
How about we add a field to PGPROC (or is there a better place?) called
shouldExit. pg_terminate_backend will set this field to "true" in the
target backend, and then send the normal "cancel query" signal.
The receiving backend will check for this flag in PostgresMain, and
perform a proc_exit(0) if it is set.
This way, the net effect of doing pg_terminate_backend() will be that of
query cancel followed by the "lost connection to client" path. Both of
which should be well tested by now.
I hacked up a really quick test, and it seems to be working in theory.
But it still requires me to send some data (such as a dummy query) to
the backend before it exits. This is because server side libpq blocks
when reading and ignores signals at this time. I believe the fix for
this would be to pass a flag down to the libpq routines that we want to
be abort in case of signal+flag, set only when doing the "main call" to
recv, so we can kill idle process.
But I naturally wanted to float the idea here before digging in with
further coding. Does this idea have any merit, or does it just seem
stupid? ;-) (hey, if it is, at least it was a try..)
//Magnus