headers
Rob Lemley | 10 Aug 2007 18:50
Favicon

PQCancel

I am interested in adding PQCancel (and friends) support to libpqxx.

I've found one mention of it in the TODO
(http://pqxx.org/development/libpqxx/changeset/825)
but it seems to have been removed from the current TODO.

Currently we use PQrequestCancel() to stop long running queries
when our application server (ie postgresql client) must shutdown.

Before I go further, I was wondering anyone has insights
about using PQCancel (PQrequestCancel is deprecated),
and/or implementing a cancel function in libpqxx (presumably
as a member of the connection_base class).

Comments?

Thanks,
Rob
Permalink | Reply |
headers
Jeroen T. Vermeulen | 12 Aug 2007 07:54
Picon
Picon
Favicon

Re: PQCancel

On Fri, August 10, 2007 23:50, Rob Lemley wrote:
> I am interested in adding PQCancel (and friends) support to libpqxx.
>
> I've found one mention of it in the TODO
> (http://pqxx.org/development/libpqxx/changeset/825)
> but it seems to have been removed from the current TODO.
>
> Currently we use PQrequestCancel() to stop long running queries
> when our application server (ie postgresql client) must shutdown.
>
> Before I go further, I was wondering anyone has insights
> about using PQCancel (PQrequestCancel is deprecated),
> and/or implementing a cancel function in libpqxx (presumably
> as a member of the connection_base class).

Interesting idea.  A "cancel" option could make sense in three places:

1. In connection_base for multi-threaded programs.  This will take some
careful thought about thread synchronization: what happens to
lazyconnections that may be initialized concurrently with the cancel
request, or worse, to asyncconnections?  The implementation may have to
figure out whether it's supposed to be canceling a connection attempt or a
query.

2. In pipeline, the only place where arbitrary queries can be executed
asynchronously.  Here the worry is semantics: do you set a specific query
to cancel, or just "whatever is going on"?

3. As a timeout option for connection_base::exec()!  It may invite more
cancellations than is really healthy, but it'd be a very user-friendly way
(Continue reading)

Permalink | Reply |
headers
Bart Samwel | 12 Aug 2007 09:39

Re: PQCancel

Hi Jeroen,

Let me add my EUR 0.02. There are two typical use cases for a "cancel", 
I guess:

1. User interaction (the user cancels processes that take too long).
2. "Real time" (the answer doesn't matter anymore after some deadline 
has passed).

Jeroen T. Vermeulen wrote:
> 3. As a timeout option for connection_base::exec()!  It may invite more
> cancellations than is really healthy, but it'd be a very user-friendly way
> to support realtime-ish behaviour.  User interaction, for instance, is a
> very common realtime task.

...but generally intended to be a precise one if the user doesn't 
manually cancel what he's waiting for. So timeouts are generally not the 
thing. Think of loading web pages: there's a network timeout of several 
minutes, but there's also a "stop" button. I would be very annoyed if I 
would replace this with only a timeout, but not with only a stop button.

And consider "real-time monitoring" software, e.g. something displaying 
a graph. If the data doesn't get there on time for a once-a-second graph 
update, should the query be cancelled? No: otherwise it probably won't 
get there on time *every* second. Instead, the software lowers its 
update frequency to what the database can provide. However, the query 
should be canceled when the user tries to exit the application. :-)

That is to say, I like the option of a timeout, and I think it may be 
very useful for non-interactive tasks, but I think for interactive use
(Continue reading)

Permalink | Reply |
headers
Jeroen T. Vermeulen | 13 Aug 2007 05:29
Picon
Picon
Favicon

Re: PQCancel

On Sun, August 12, 2007 14:39, Bart Samwel wrote:

> ...but generally intended to be a precise one if the user doesn't
> manually cancel what he's waiting for. So timeouts are generally not the
> thing. Think of loading web pages: there's a network timeout of several
> minutes, but there's also a "stop" button. I would be very annoyed if I
> would replace this with only a timeout, but not with only a stop button.

But if there's an application running behind the web page, and a query
inside that application is taking too long, then at some point the
application must conclude that:

1. The user isn't going to get an answer in reasonable time, and it may be
better to tell him "no can do" than to keep him waiting.

2. There may be something seriously wrong with the query, or with system
load, and the application had better abort the query to protect itself.

The user is likely at some point to move on to something else anyway, and
it doesn't make much sense to continue processing.  Worst case, the user
has already tried to reload the page a few times and you may have several
instances of the problem query running at the same time.

> And consider "real-time monitoring" software, e.g. something displaying
> a graph. If the data doesn't get there on time for a once-a-second graph
> update, should the query be cancelled? No: otherwise it probably won't
> get there on time *every* second.

Yes, if the job can't make its real-time constraint, it should be
canceled.  If the application consistently can't make its time goals, then
(Continue reading)

Permalink | Reply |
headers
Bart Samwel | 13 Aug 2007 09:55

Re: PQCancel

Jeroen T. Vermeulen wrote:
> On Sun, August 12, 2007 14:39, Bart Samwel wrote:
> 
>> ...but generally intended to be a precise one if the user doesn't
>> manually cancel what he's waiting for. So timeouts are generally not the
>> thing. Think of loading web pages: there's a network timeout of several
>> minutes, but there's also a "stop" button. I would be very annoyed if I
>> would replace this with only a timeout, but not with only a stop button.
> 
> But if there's an application running behind the web page, and a query
> inside that application is taking too long, then at some point the
> application must conclude that:
> 
> 1. The user isn't going to get an answer in reasonable time, and it may be
> better to tell him "no can do" than to keep him waiting.
> 
> 2. There may be something seriously wrong with the query, or with system
> load, and the application had better abort the query to protect itself.
> 
> The user is likely at some point to move on to something else anyway, and
> it doesn't make much sense to continue processing.  Worst case, the user
> has already tried to reload the page a few times and you may have several
> instances of the problem query running at the same time.

Ahhh, I wasn't considering the web application case. I was only 
considering the desktop application case, in which case there's no 
reloading and TCP timeouts to consider.

>> And consider "real-time monitoring" software, e.g. something displaying
>> a graph. If the data doesn't get there on time for a once-a-second graph
(Continue reading)

Permalink | Reply |

Gmane