| From: | "Eric Simon" <esimon(at)theiqgroup(dot)com> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Problem Using PQcancel in a Synchronous Query |
| Date: | 2010-08-24 16:43:59 |
| Message-ID: | 42EB0E1F7AB04432B464F069A27896EB@Masterchief |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom,
That was it! My implementation of cancel() was swallowing the result
message. Thanks so much, I've got it working now.
--
Eric Simon
The IQ Group, Inc.
-----Original Message-----
From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: Monday, August 23, 2010 7:06 PM
To: Eric Simon
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Problem Using PQcancel in a Synchronous Query
"Eric Simon" <esimon(at)theiqgroup(dot)com> writes:
> Now that I've established some context, here's where I'm at: I've written
> $sth->cancel() for DBD::Pg using PQcancel(), and it works (it returns the
> status 57014: QUERY CANCELED). The problem is that the $sth->execute call
> (which resides between the two alarm() calls above) doesn't continue on,
but
> rather stays frozen, waiting for data. Does PQcancel not communicate back
> to the execute statement so that it unblocks?
Um ... PQcancel returns no such thing, only true or false. I'm guessing
you've coded your signal handler in such a way that it eats the query
result message intended for the mainline execute code. You should not
be calling anything except PQcancel itself in the signal handler.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-08-24 16:53:45 | Re: Unable to drop role |
| Previous Message | Alex Hunsaker | 2010-08-24 16:28:56 | Re: Unable to drop role |