Re: Testing LISTEN/NOTIFY more effectively
| От | Tom Lane |
|---|---|
| Тема | Re: Testing LISTEN/NOTIFY more effectively |
| Дата | |
| Msg-id | 20277.1564272133@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Testing LISTEN/NOTIFY more effectively (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Testing LISTEN/NOTIFY more effectively
|
| Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes:
> Polling for notices on the blocked connection before printing anything
> ought to practically be reliable. Theoretically I think it still allows
> for some reordering, e.g. because there was packet loss on one, but not
> the other connection.
As long as it's a local connection, packet loss shouldn't be a problem
;-). I'm slightly more worried about the case of more than one bufferful
of NOTICE messages: calling PQconsumeInput isn't entirely guaranteed to
absorb *all* available input. But for the cases we actually need to
deal with, I think probably the patch as I sent it is OK. We could
complicate matters by going around the loop extra time(s) to verify
that select() thinks no data is waiting, but I doubt it's worth the
complexity.
regards, tom lane
В списке pgsql-hackers по дате отправления: