From 3f29d39195cff1a40ae039cac24594ca103321d2 Mon Sep 17 00:00:00 2001 From: Anthonin Bonnefoy Date: Wed, 30 Oct 2024 09:11:30 +0100 Subject: Consider pipeline implicit transaction as a transaction block When using pipeline with implicit transaction, a transaction will start from the first command and be committed with the Sync message. Functions like IsInTransactionBlock and PreventInTransactionBlock already assimilate this implicit transaction as a transaction block. However, this is not the case in CheckTransactionBlock. This function is called for things like warning when set local is used outside of a transaction block. This patch changes the transaction state to an implicit transaction block when a new command is processed while pipelining was detected. This remove the need to check for XACT_FLAGS_PIPELINING in IsInTransactionBlock and PreventInTransactionBlock since the transaction state now reflects the ongoing transaction block. This allows to avoid warning when `set local` is called within a pipeline, and makes the detection of transaction block coherent with what's done in IsInTransactionBlock and PreventInTransactionBlock. A known limitation of this patch: the first command won't be detected as part of a transaction block. The implicit block only starts at the second command so the `set local` warnings will still happen if called first. --- doc/src/sgml/libpq.sgml | 63 ++++++++++++++++++++++++++++++ src/backend/access/transam/xact.c | 13 ------ src/backend/tcop/postgres.c | 18 +++++++++ src/test/regress/expected/psql.out | 16 +++++--- src/test/regress/sql/psql.sql | 7 ++-- 5 files changed, 95 insertions(+), 22 deletions(-) diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index bfefb1289e8..fd9759b3294 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -6092,6 +6092,69 @@ UPDATE mytable SET x = x + 1 WHERE id = 42; multiple transactions (see ). + + + Pipeline and Implicit Transaction Block + + + If no explicit transaction block is provided, statements executed in pipeline mode + will be executed in an implicit transaction block. This transaction block will be + committed at the next synchronization point. If the pipeline was aborted due to query + error, all changes done since the last synchronization point will be rollbacked. + +-- \startpipeline, \endpipeline and \syncpipeline are psql specific meta-commands +\startpipeline +UPDATE mytable SET x = 3 WHERE id = 42 \bind \g + +-- The synchronization point will commit the implicit transaction block +\syncpipeline + +-- Starts of a new implicit transaction block +UPDATE mytable SET x = 4 WHERE id = 42 \bind \g +UPDATE mytable \bind \g +-- The second query is invalid and will abort the pipeline +-- All changes done after \syncpipeline will be rollbacked +-- Result at the end of the pipeline: x=3 +\endpipeline + + + + + On the server, the start of a pipeline will only be detected when the first command ends without + being committed with a synchronization point. This leads to a different behavior between the + first command of a pipeline and the rest as the first statement won't be detected as running in + a transaction block. This will impact commands that need to run within a statement block, + like LOCK, which need to run in a transaction block and will fail if it's the first + command of a pipeline but works . + +-- LOCK is the first command of the pipeline and won't be seen as part of an implicit +-- transaction block. It will fail with the following message +-- ERROR: LOCK TABLE can only be used in transaction blocks +\startpipeline +LOCK mytable \bind \g +SELECT * FROM mytable \bind \g +\endpipeline + +-- LOCK is the second command of the pipeline and will succeed as it will detected as +-- part of an implicit transaction block +\startpipeline +SELECT 1 \bind \g +LOCK mytable \bind \g +SELECT * FROM mytable \bind \g +\endpipeline + +-- LOCK is the first command after a synchronisation point and will fail as it's +-- not detected as part of an implicit transaction block +\startpipeline +SELECT 1 \bind \g +\syncpipeline +LOCK mytable \bind \g +SELECT * FROM mytable \bind \g +\endpipeline + + + + diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c index b7ebcc2a557..1eccb78ddc4 100644 --- a/src/backend/access/transam/xact.c +++ b/src/backend/access/transam/xact.c @@ -3659,16 +3659,6 @@ 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? */ @@ -3780,9 +3770,6 @@ IsInTransactionBlock(bool isTopLevel) if (IsSubTransaction()) return true; - if (MyXactFlags & XACT_FLAGS_PIPELINING) - return true; - if (!isTopLevel) return true; diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c index 184b8301687..bd424767176 100644 --- a/src/backend/tcop/postgres.c +++ b/src/backend/tcop/postgres.c @@ -2780,6 +2780,17 @@ start_xact_command(void) xact_started = true; } + else if (MyXactFlags & XACT_FLAGS_PIPELINING) + { + /* + * When the first Execute message is completed, following commands + * will be done in an implicit transaction block created via + * pipelining. The transaction state needs to be updated to an + * implicit block if we're not already in a transaction block (like + * one started by an explicit BEGIN). + */ + BeginImplicitTransactionBlock(); + } /* * Start statement timeout if necessary. Note that this'll intentionally @@ -4991,6 +5002,13 @@ PostgresMain(const char *dbname, const char *username) case PqMsg_Sync: pq_getmsgend(&input_message); + + /* + * If pipelining was used, we may be in an implicit + * transaction block. Close it before calling + * finish_xact_command. + */ + EndImplicitTransactionBlock(); finish_xact_command(); valgrind_report_error_query("SYNC message"); send_ready_for_query = true; diff --git a/src/test/regress/expected/psql.out b/src/test/regress/expected/psql.out index 8bd9b26a257..addb3d7dcc4 100644 --- a/src/test/regress/expected/psql.out +++ b/src/test/regress/expected/psql.out @@ -7027,7 +7027,8 @@ SELECT COUNT(*) FROM psql_pipeline \bind \g -- pipelining and transaction block behaviour -- set local will issue a warning when modifying a GUC outside of a transaction block -- The change will still be valid as a pipeline runs within an implicit transaction block --- Sending a sync will commit the implicit transaction block. +-- Sending a sync will commit the implicit transaction block. The first command after a sync +-- won't be seen as belonging to a pipeline. \startpipeline SET LOCAL statement_timeout='1h' \bind \g SHOW statement_timeout \bind \g @@ -7042,7 +7043,6 @@ WARNING: SET LOCAL can only be used in transaction blocks 1h (1 row) -WARNING: SET LOCAL can only be used in transaction blocks statement_timeout ------------------- 0 @@ -7064,7 +7064,7 @@ SELECT $1 \bind 2 \g 1 (1 row) -ERROR: REINDEX CONCURRENTLY cannot be executed within a pipeline +ERROR: REINDEX CONCURRENTLY cannot run inside a transaction block -- Reindex concurrently will work if it's the first command of a pipeline \startpipeline REINDEX TABLE CONCURRENTLY psql_pipeline \bind \g @@ -7083,13 +7083,13 @@ ROLLBACK TO SAVEPOINT a \bind \g SELECT $1 \bind 2 \g \endpipeline ERROR: SAVEPOINT can only be used in transaction blocks --- Lock command will fail as pipeline is not seen as a transaction block +-- Lock command will fail as first pipeline command is not seen as a transaction block \startpipeline LOCK psql_pipeline \bind \g SELECT $1 \bind 2 \g \endpipeline ERROR: LOCK TABLE can only be used in transaction blocks --- Lock command will fail in the middle of the pipeline as it's not seen as a transaction block +-- Lock command will succeed after the first command as pipeline will be seen as an implicit transaction block \startpipeline SELECT $1 \bind 1 \g LOCK psql_pipeline \bind \g @@ -7100,4 +7100,8 @@ SELECT $1 \bind 2 \g 1 (1 row) -ERROR: LOCK TABLE can only be used in transaction blocks + ?column? +---------- + 2 +(1 row) + diff --git a/src/test/regress/sql/psql.sql b/src/test/regress/sql/psql.sql index ba613a6d435..fcb6d2b30b8 100644 --- a/src/test/regress/sql/psql.sql +++ b/src/test/regress/sql/psql.sql @@ -2046,7 +2046,8 @@ SELECT COUNT(*) FROM psql_pipeline \bind \g -- set local will issue a warning when modifying a GUC outside of a transaction block -- The change will still be valid as a pipeline runs within an implicit transaction block --- Sending a sync will commit the implicit transaction block. +-- Sending a sync will commit the implicit transaction block. The first command after a sync +-- won't be seen as belonging to a pipeline. \startpipeline SET LOCAL statement_timeout='1h' \bind \g SHOW statement_timeout \bind \g @@ -2077,13 +2078,13 @@ ROLLBACK TO SAVEPOINT a \bind \g SELECT $1 \bind 2 \g \endpipeline --- Lock command will fail as pipeline is not seen as a transaction block +-- Lock command will fail as first pipeline command is not seen as a transaction block \startpipeline LOCK psql_pipeline \bind \g SELECT $1 \bind 2 \g \endpipeline --- Lock command will fail in the middle of the pipeline as it's not seen as a transaction block +-- Lock command will succeed after the first command as pipeline will be seen as an implicit transaction block \startpipeline SELECT $1 \bind 1 \g LOCK psql_pipeline \bind \g -- 2.39.5 (Apple Git-154)