Thread: 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