Обсуждение: Query cancellation and OOB

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?
Certain commands could be issued there, outside of the main connection
(possibly even via UDP) as one-shot deals (not requiring a persistent
connection) and the postmaster could pass the information on to the
appropriate backend in a nice, intrusive fashion. :)

-Brandon :)

>
>    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?
> Certain commands could be issued there, outside of the main connection
> (possibly even via UDP) as one-shot deals (not requiring a persistent
> connection) and the postmaster could pass the information on to the
> appropriate backend in a nice, intrusive fashion. :)

Yes, but you have to make sure the cancel is ONLY coming from the proper
client.  The signal thing is nice, so how do you simulate that, unless
you have the postmaster send the signal to the proper child?

I hate to add lots of stuff just to get CANCEL to work on unix domain
sockets.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

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