Thread: 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