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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brian Curnow <bcurnow(at)sonnet(dot)com>
Cc: pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] perl5 Should consumeInput obliterate unretrieved Notifys?
Date: 1999-07-30 01:19:22
Message-ID: 9462.933297562@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Brian Curnow <bcurnow(at)sonnet(dot)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

Browse pgsql-interfaces by date

  From Date Subject
Next Message John David Garza 1999-07-30 01:30:34 jdbc, pgsql6.5.1, large objects
Previous Message Christopher Hutton 1999-07-30 01:17:31 error question