From 1cca4a75ffb82c7e0497e6195b7fb3ed44dc430e Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 13 Dec 2022 14:23:59 -0500 Subject: [PATCH] Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode. Commits f92944137 et al. made IsInTransactionBlock() set the XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false", on the grounds that that kept its API promises equivalent to those of PreventInTransactionBlock(). This turns out to be a bad idea though, because it allows an ANALYZE in a pipelined series of commands to cause an immediate commit, which is unexpected. Furthermore, if we return "false" then we have another issue, which is that ANALYZE will decide it's allowed to do internal commit-and-start-transaction sequences, thus possibly unexpectedly committing the effects of previous commands in the pipeline. To fix the latter situation, invent another transaction state flag XACT_FLAGS_PIPELINING, which explicitly records the fact that we have executed some extended-protocol command and not yet seen a commit for it. Then, require that flag to not be set before allowing InTransactionBlock() to return "false". Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT without fear of causing problems. This means that the API guarantees of IsInTransactionBlock now diverge from PreventInTransactionBlock, which is mildly annoying, but it seems OK given the very limited usage of IsInTransactionBlock. (In any case, a caller preferring the old behavior could always set NEEDIMMEDIATECOMMIT for itself.) For consistency also require XACT_FLAGS_PIPELINING to not be set in PreventInTransactionBlock. This too is meant to prevent commands such as CREATE DATABASE from silently committing previous commands in a pipeline. Per report from Peter Eisentraut. As before, back-patch to all supported branches (which sadly no longer includes v10). Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com --- doc/src/sgml/protocol.sgml | 9 +++++---- src/backend/access/transam/xact.c | 28 ++++++++++++++++++---------- src/backend/tcop/postgres.c | 12 ++++++++++++ src/include/access/xact.h | 7 +++++++ 4 files changed, 42 insertions(+), 14 deletions(-) diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index e91611157c..23ee0b84b2 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1093,9 +1093,10 @@ SELCT 1/0; implicit ROLLBACK if they failed. However, there are a few DDL commands (such as CREATE DATABASE) that cannot be executed inside a transaction block. If one of - these is executed in a pipeline, it will, upon success, force an - immediate commit to preserve database consistency. - A Sync immediately following one of these has no effect except to + these is executed in a pipeline, it will fail unless it is the first + command in the pipeline. Furthermore, upon success it will force an + immediate commit to preserve database consistency. Thus a Sync + immediately following one of these commands has no effect except to respond with ReadyForQuery. @@ -1103,7 +1104,7 @@ SELCT 1/0; When using this method, completion of the pipeline must be determined by counting ReadyForQuery messages and waiting for that to reach the number of Syncs sent. Counting command completion responses is - unreliable, since some of the commands may not be executed and thus not + unreliable, since some of the commands may be skipped and thus not produce a completion message. diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c index d578f11c4d..b304a85d08 100644 --- a/src/backend/access/transam/xact.c +++ b/src/backend/access/transam/xact.c @@ -3378,6 +3378,16 @@ PreventInTransactionBlock(bool isTopLevel, const char *stmtType) errmsg("%s cannot run inside a subtransaction", stmtType))); + /* + * inside a pipeline that has started an implicit transaction? + */ + if (MyXactFlags & XACT_FLAGS_PIPELINING) + ereport(ERROR, + (errcode(ERRCODE_ACTIVE_SQL_TRANSACTION), + /* translator: %s represents an SQL statement name */ + errmsg("%s cannot be executed within a pipeline", + stmtType))); + /* * inside a function call? */ @@ -3468,9 +3478,11 @@ CheckTransactionBlock(bool isTopLevel, bool throwError, const char *stmtType) * a transaction block than when running as single commands. ANALYZE is * currently the only example. * - * If this routine returns "false", then the calling statement is - * guaranteed that if it completes without error, its results will be - * committed immediately. + * If this routine returns "false", then the calling statement is allowed + * to perform internal transaction-commit-and-start cycles; there is not a + * risk of messing up any transaction already in progress. (Note that this + * is not the identical guarantee provided by PreventInTransactionBlock, + * since we will not force a post-statement commit.) * * isTopLevel: passed down from ProcessUtility to determine whether we are * inside a function. @@ -3488,6 +3500,9 @@ IsInTransactionBlock(bool isTopLevel) if (IsSubTransaction()) return true; + if (MyXactFlags & XACT_FLAGS_PIPELINING) + return true; + if (!isTopLevel) return true; @@ -3495,13 +3510,6 @@ IsInTransactionBlock(bool isTopLevel) CurrentTransactionState->blockState != TBLOCK_STARTED) return true; - /* - * If we tell the caller we're not in a transaction block, then inform - * postgres.c that it had better commit when the statement is done. - * Otherwise our report could be a lie. - */ - MyXactFlags |= XACT_FLAGS_NEEDIMMEDIATECOMMIT; - return false; } diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c index 1af5817383..bd07b2a239 100644 --- a/src/backend/tcop/postgres.c +++ b/src/backend/tcop/postgres.c @@ -2116,6 +2116,12 @@ exec_execute_message(const char *portal_name, long max_rows) */ CommandCounterIncrement(); + /* + * Set XACT_FLAGS_PIPELINING whenever we complete an Execute + * message without immediately committing the transaction. + */ + MyXactFlags |= XACT_FLAGS_PIPELINING; + /* full command has been executed, reset timeout */ disable_statement_timeout(); } @@ -2128,6 +2134,12 @@ exec_execute_message(const char *portal_name, long max_rows) /* Portal run not complete, so send PortalSuspended */ if (whereToSendOutput == DestRemote) pq_putemptymessage('s'); + + /* + * Set XACT_FLAGS_PIPELINING whenever we suspend an Execute message, + * too. + */ + MyXactFlags |= XACT_FLAGS_PIPELINING; } /* diff --git a/src/include/access/xact.h b/src/include/access/xact.h index 80e10af3ca..3a27ac0410 100644 --- a/src/include/access/xact.h +++ b/src/include/access/xact.h @@ -109,6 +109,13 @@ extern int MyXactFlags; */ #define XACT_FLAGS_NEEDIMMEDIATECOMMIT (1U << 2) +/* + * XACT_FLAGS_PIPELINING - set when we complete an extended-query-protocol + * Execute message. This is useful for detecting that an implicit transaction + * block has been created via pipelining. + */ +#define XACT_FLAGS_PIPELINING (1U << 3) + /* * start- and end-of-transaction callbacks for dynamically loaded modules */