From 777b51cde0cc64f064378a4b11eeae7a821b85f0 Mon Sep 17 00:00:00 2001 From: "(Jerome)Junfeng Yang" Date: Fri, 30 Oct 2020 14:06:46 +0800 Subject: [PATCH] Reset wrote_xlog in pg_conn to avoid keeping old value. (#11077) On QD, it tracks whether QE wrote_xlog in the libpq connection. The logic is, if QE writes xlog, it'll send a libpq msg to QD. But the msg is sent in ReadyForQuery. So, before QE execute this function, the QE may already send back results to QD. Then when QD process this message, it does not read the new wrote_xlog value. This makes the connection still contains the previous dispatch wrote_xlog value, which will affect whether choosing one phase commit. The issue only happens when the QE flush the libpq msg before the ReadyForQuery function, hard to find a case to cover it. I found the issue when I playing the code to send some information from QE to QD. And it breaks the gangsize test which shows the commit info. --- src/backend/cdb/dispatcher/cdbdisp_async.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/backend/cdb/dispatcher/cdbdisp_async.c b/src/backend/cdb/dispatcher/cdbdisp_async.c index 9cbce934a4..262c02c1b7 100644 --- a/src/backend/cdb/dispatcher/cdbdisp_async.c +++ b/src/backend/cdb/dispatcher/cdbdisp_async.c @@ -915,8 +915,18 @@ processResults(CdbDispatchResult *dispatchResult) } if (segdbDesc->conn->wrote_xlog) + { MarkTopTransactionWriteXLogOnExecutor(); + /* + * Reset the worte_xlog here. Since if the received pgresult not process + * the xlog write message('x' message sends from QE in ReadyForQuery), + * the value may still refer to previous dispatch statement. Which may + * always mark current top transaction has wrote xlog on executor. + */ + segdbDesc->conn->wrote_xlog = false; + } + /* * Attach the PGresult object to the CdbDispatchResult object. */ -- GitLab