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.kyotaro@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
messagesby the next command already came before getting the result set. Prevent that by letting pqParseInput3 return
justafter 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
