Hello. While looking [1], I noticed that NOTICE messages of the next command is processed before PQgetResult returns. Clients can receive such spurious NOTICE messages.
Looking pqParseInput3, its main loop seems considered to exit after complete messages is processed. (As I read.) > * Loop to parse successive complete messages available in the buffer. But actually, 'C' message doesn't work that way. I think we should do as the comment suggests. Clients still can process async messages or (somehow issued) NOTICE messages in later calls. [1]: https://www.postgresql.org/message-id/alpine.DEB.2.21.1904132231510.8961@lancre regards. -- Kyotaro Horiguchi NTT Open Source Software Center
>From 6dbc907142d7aaba7f02e6585e3fa407511725bc Mon Sep 17 00:00:00 2001 From: Kyotaro Horiguchi <horiguchi.kyot...@lab.ntt.co.jp> Date: Fri, 26 Jul 2019 12:51:56 +0900 Subject: [PATCH] Don't parse further messages after COMPLETE message There is a case where notify processor is called by spurious messages before PQgetResult returns a result set if NOTICE messages by the next command already came before getting the result set. Prevent that by letting pqParseInput3 return just after processing 'C' message. --- src/interfaces/libpq/fe-protocol3.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/interfaces/libpq/fe-protocol3.c b/src/interfaces/libpq/fe-protocol3.c index bbba48bc8b..0ea6a918ab 100644 --- a/src/interfaces/libpq/fe-protocol3.c +++ b/src/interfaces/libpq/fe-protocol3.c @@ -437,6 +437,10 @@ pqParseInput3(PGconn *conn) /* trust the specified message length as what to skip */ conn->inStart += 5 + msgLength; } + + /* As we get ready now, give caller a chance to process the result */ + if (conn->asyncStatus == PGASYNC_READY) + return; } } -- 2.16.3