Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> It just occurred to me, while browsing through the last hacker's
>> digest, that OOB might be more trouble than it's worth. What about
>> having the Postmaster listen on a second socket as an alternative?
I kinda like this. You could eliminate the need for signal() at all,
which seems like a good idea --- the postmaster could just set the
cancel flag directly in shared memory.
> Yes, but you have to make sure the cancel is ONLY coming from the proper
> client.
Or his authorized designee. In a multi-process application I think it
might be legitimate for a thread other than the one talking to the
backend to want to issue the cancel.
How about this: during the startup protocol, the client is sent the PID
of the backend, as well as some random number custom-generated for that
connection. To execute a cancel request, the postmaster must be handed
back both the PID of a live backend and the matching random number.
Further protection could be provided by requiring the cancel requester
to go through a full authorization handshake.
BTW I see no need for the postmaster to listen on a separate socket for
this purpose. The main connection-accepting socket would do fine. This
is just a different kind of request message that can arrive there.
regards, tom lane