Обсуждение: Cancell/OOB over a Unix Domain Socket

> Bruce Wrote..
>
> > Bruce Momjian wrote:
> >
> > > OK, thanks to Tom Lane's many patches, I have query cancel working on my
> > > machine.  However, it is not working with Unix domain sockets.  I get:
> > >
> > >         Cannot send cancel request:
> > >         PQrequestCancel() -- couldn't send OOB data: errno=45
> > >         Operation not supported
> > >
> > > This is under BSDI 3.1.
> > >
> > > Do Unix Domain sockets support OOB(out-of-band) data?
> > >
> >
> > Unix domain sockets don't support OOB (Stevens, Unix Network Programming).
>
> Yea, I found that too, late last night, Section 6.14, page 332.
>
> 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.
>
> Any ideas?
>

Think..Think..Think..

If the notification has to be a signal, it has to come from a process
with the same pid (or running as root).  That means another processes,
perhaps listening to another socket.  To interrupt the user process
connects to the other (Unix domain) socket, sends some sort of cancell
id, and closes.  The signaller process then signalls the backend.  Ugly.

Hmm... The postmaster is still hanging around, isn't it.  So to cancel
you make another identical connection to the postmaster and send a different
code.  A bit less ugly.

Is the cancell flag in shared memory?  The postmaster could set it directly
without the signal() call.   In fact, if it were in shared memory the
postmaster could take a peek and see how much of the query was completed,
if some sort of counter was maintained.

Wish I could come up with something better.  Another example of the
fact that our beloved operating system does indeed have a few warts.

-- cary

> Think..Think..Think..
>
> If the notification has to be a signal, it has to come from a process
> with the same pid (or running as root).  That means another processes,
> perhaps listening to another socket.  To interrupt the user process
> connects to the other (Unix domain) socket, sends some sort of cancell
> id, and closes.  The signaller process then signalls the backend.  Ugly.

Yep.

>
> Hmm... The postmaster is still hanging around, isn't it.  So to cancel
> you make another identical connection to the postmaster and send a different
> code.  A bit less ugly.

Yep.

>
> Is the cancell flag in shared memory?  The postmaster could set it directly
> without the signal() call.   In fact, if it were in shared memory the
> postmaster could take a peek and see how much of the query was completed,
> if some sort of counter was maintained.

Shared memory really doesn't buy us much.  If we have privs to attach to
shared memory, we have enough to send a signal, and because it just
needs to tell it to stop, extra bandwidth of shared memory isn't buying
us anything.  In fact, it could make it worse, because we would have to
synchronize access to the shared memory.

>
> Wish I could come up with something better.  Another example of the
> fact that our beloved operating system does indeed have a few warts.

I am still looking for that silver bullet.

--
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)