From: Brian Curnow <bcurnow@sonnet.com>
To: pgsql-interfaces@postgresql.org
Subject: perl5 Should consumeInput obliterate unretrieved Notifys?
Date: Thu, 29 Jul 1999 16:40:09 -0700
Message-ID: <37A0E659.5F423AA8@sonnet.com> (raw)
Hello,
I've got a Perl script that makes the following series of calls:
conn->exec(SELECT
...
conn->exec(UPDATE
...
$conn->socket
select (..) [with short timeout]
conn->consumeInput
conn->notifies
What I am seeing is that if a Notify arrives between the SELECT and
UPDATE, the exec(UPDATE) call consumes the notify, and when the next
consumeInput is eventually called, the notify disappears. The easy fix
is obviously to call notifies() before even starting the select(), but I
wonder if the loss of notify is correct.
The docs for libpq state that you should call notifies() after each
PQexec or PQgetResult, but I figured that was because a future select()
would not catch the notify since PQexec already had read it, and you
might wait (possibly forever) without checking. Further up in the
documentation, it states
"Once a notification is returned from PQnotifies, it is considered
handled and will be removed from the list of notifications."
which would imply the loss of the notify is incorrect. perldoc Pg
doesn't say anything contradictory.
Does anyone have thoughts on this?
Brian Curnow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: bcurnow@sonnet.com
Subject: Re: perl5 Should consumeInput obliterate unretrieved Notifys?
In-Reply-To: <37A0E659.5F423AA8@sonnet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox