Re: [HACKERS] Proposal for async support in libpq - Mailing list pgsql-hackers

> > Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > > This all looks good.  Another thing we really need it to be able to
> > > cancel queries.  This would be a big win, and looks like it could fit
> > > into the scheme here.
> >
> > I thought about proposing a PQcancelAsync that would cancel the active
> > query-in-progress.  But that would require support on the backend side,
> > and I am far from competent to make it happen.  (libpq is simple enough
> > that I'm not afraid to rewrite it, but making major mods to the backend
> > is another story.  I just got here this week...)
> >
> > If anyone who does know what they're doing is willing to make the
> > necessary backend mods, I'm all for it.  The libpq side would be
> > easy enough.
> >
> > How would such cancellation interact with transactions, btw?  Would
> > you expect it to roll back only the current command, or abort the
> > whole transaction?  We'd also have to consider corner cases, like
> > when the backend has already finished the query by the time it gets
> > the cancel request.
>
> It is pretty easy, just an elog(ERROR) would do it.  The issue is
> allowing the backend to see the request.  We can put some checks in
> tcop/postgres.c as it moves from module to module, and something in the
> executor to check for the cancel, and do an elog(ERROR).  It would be
> nice if it arrived as out-of-band data, so we could check for input
> quickly without having to actually process it if it is not a cancel
> notification.
>
> The out-of-band data will send a SIGURG signal to the backend, and we
> can set a global variable, and check the variable at various places.
>
> To do all this, we need to be able to send a query, and not have it
> block, and it seems you are giving us this capability.
>
> You supply the indication to the backend, and I will see that the
> backend processes it properly.

Old news I know, but I was saving it to follow up and then ...

I agree completely with Bruces proposal for handling this in the back-end.
I have recently done something very similar for another database product.

The important points are:

 - the signal handler can only set a single global variable. No other action
   is to be done in the handler.

 - the variable is to be tested only at well defined times where the recovery
   from an elog() can be handled correctly. It is nice if this test is
   "frequent, but not too frequent". At scan begin time is fairly good, and
   for large scans perhaps every few pages. Every row is too often. When
   stepping to a new plan node is also good.

 - There should be a further global flag to disable recognition of the
   cancel. This is used for example during an in progress elog() -> cleanup
   sequence. The cleanup code is not really reentrant so an elog() in the
   middle of an elog is likely to leave an inconsistant state.

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
 and someone who knows less will correct me if I'm right."
               --David Palmer (palmer@tybalt.caltech.edu)