Обсуждение: perl5 Should consumeInput obliterate unretrieved Notifys?

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

Brian Curnow <bcurnow@sonnet.com> writes:
> 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.

"Disappears"?  It certainly should not disappear; the event should be
sitting patiently in the list of notify events not yet returned by
PQnotifies().

> The docs for libpq state that you should call notifies() after each
> PQexec or PQgetResult,

What they mean is that each such call might possibly cause events to
become available from PQnotifies().  PQnotifies() itself just pulls
notify records from a queue of pending notify records; it does not try
to consume input from the backend.  Those other routines consume input,
and append any notify messages they come across to the queue for
PQnotifies().

You don't have to call PQnotifies() oftener than it makes sense for your
application logic to try to process notify events...

Perhaps you are confusing the existence of a select() read-ready
condition with the availability of a NOTIFY message.  They're not
the same thing.  consumeInput will clear the select() condition,
but that may or may not result in the availability of a NOTIFY.

You might want to think about checking PQnotifies immediately *before*
blocking at select(), rather than after...
        regards, tom lane