]> granicus.if.org Git - postgresql/commit
Client-side fixes for delayed NOTIFY receipt.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 20 Oct 2018 02:22:57 +0000 (22:22 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 20 Oct 2018 02:22:57 +0000 (22:22 -0400)
commit4247db62522fafd1d4c045c5a432f50f2f05c0e0
treee60fbb4e14b658f88681dc893e3817b59449e3fa
parent2ddb9149d14de9a2e7ac9ec6accf3ad442702b24
Client-side fixes for delayed NOTIFY receipt.

PQnotifies() is defined to just process already-read data, not try to read
any more from the socket.  (This is a debatable decision, perhaps, but I'm
hesitant to change longstanding library behavior.)  The documentation has
long recommended calling PQconsumeInput() before PQnotifies() to ensure
that any already-arrived message would get absorbed and processed.
However, psql did not get that memo, which explains why it's not very
reliable about reporting notifications promptly.

Also, most (not quite all) callers called PQconsumeInput() just once before
a PQnotifies() loop.  Taking this recommendation seriously implies that we
should do PQconsumeInput() before each call.  This is more important now
that we have "payload" strings in notification messages than it was before;
that increases the probability of having more than one packet's worth
of notify messages.  Hence, adjust code as well as documentation examples
to do it like that.

Back-patch to 9.5 to match related server fixes.  In principle we could
probably go back further with these changes, but given lack of field
complaints I doubt it's worthwhile.

Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com
doc/src/sgml/libpq.sgml
src/bin/psql/common.c
src/interfaces/ecpg/ecpglib/execute.c
src/interfaces/libpq/fe-exec.c
src/test/examples/testlibpq2.c