perl5 Should consumeInput obliterate unretrieved Notifys?
От | Brian Curnow |
---|---|
Тема | perl5 Should consumeInput obliterate unretrieved Notifys? |
Дата | |
Msg-id | 37A0E659.5F423AA8@sonnet.com обсуждение исходный текст |
Ответы |
Re: [INTERFACES] perl5 Should consumeInput obliterate unretrieved Notifys?
|
Список | pgsql-interfaces |
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
В списке pgsql-interfaces по дате отправления: