Re: [INTERFACES] perl5 Should consumeInput obliterate unretrieved Notifys?

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