Re: [HACKERS] Query cancellation and OOB

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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