> I basically need some way to 'signal' the backend of a cancellation
> request. Polling the socket is not an option because it would impose
> too great a performance penalty. Maybe async-io on a read(), but that
> is not going to be very portable.
>
> I could pass the backend pid to the front end, and send a kill(SIG_URG)
> to that pid on a cancel, but the frontend can be running as a different
> user than the backend. Problem is, the only communcation channel is
> that unix domain socket.
>
> We basically need some way to get the attention of the backend,
> hopefully via some signal.
OK, I think I have a solution. I recommend we pass the backend pid to
the client as part of connection startup. Then, when the client wants
to cancel a query, it sends a cancel packet to its backend (new packet
type), and then sends that pid to the postmaster with a new packet type.
When the postmaster receives the packet with the pid, it sends a signal
to that pid/backend. The backend does a recv(MSG_PEEK) to see if it has
a pending packet with a cancel request. If it does, it cancels, if not,
it ignores it. In the read loop of the backend, all cancel requests are
ignored.
So the cancel packet to the postmaster only causes the backend to look
for a pending cancel packet.
This does a few things for us. It allows us to use cancel in unix
domain sockets, and in Java or anything that can't support OOB. In
fact, I would recommend discarding OOB in favor of this method.
Also, it does not require the postmaster to authenticate the cancel
request. This could be hard, especially if the user has to type in a
password. No one wants to type in a password to cancel a query.
Comments?
--
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)