Cancell/OOB over a Unix Domain Socket - Mailing list pgsql-hackers

From Cary B. O'Brien
Subject Cancell/OOB over a Unix Domain Socket
Date
Msg-id 199805191247.IAA24295@access2.digex.net
Whole thread Raw
Responses Re: [HACKERS] Cancell/OOB over a Unix Domain Socket
List pgsql-hackers
> 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

pgsql-hackers by date:

Previous
From: "Göran Thyni"
Date:
Subject: Re: [HACKERS] Query cancel and OOB data
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Query cancellation and OOB