Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit5c30672

Browse files
committed
Handle better implicit transaction state of pipeline mode
When using a pipeline, a transaction starts from the first command andis committed with a Sync message or when the pipeline ends.Functions like IsInTransactionBlock() or PreventInTransactionBlock()were already able to understand a pipeline as being in a transactionblock, but it was not the case of CheckTransactionBlock(). Thisfunction is called for example to generate a WARNING for SET LOCAL,complaining that it is used outside of a transaction block.The current state of the code caused multiple problems, like:- SET LOCAL executed at any stage of a pipeline issued a WARNING, evenif the command was at least second in line where the pipeline is in atransaction state.- LOCK TABLE failed when invoked at any step of a pipeline, even if itshould be able to work within a transaction block.The pipeline protocol assumes that the first command of a pipeline isnot part of a transaction block, and that any follow-up commands isconsidered as within a transaction block.This commit changes the backend so as an implicit transaction block isstarted each time the first Execute message of a pipeline has finishedprocessing, with this implicit transaction block ended once a sync isprocessed. The checks based on XACT_FLAGS_PIPELINING in the routineschecking if we are in a transaction block are not necessary: it isenough to rely on the existing ones.Some tests are added to pgbench, that can be backpatched down to v17when \syncpipeline is involved and down to v14 where \startpipeline and\endpipeline are available. This is unfortunately limited regarding theerror patterns that can be checked, but it provides coverage for variouspipeline combinations to check if these succeed or fail. These testsare able to capture the case of SET LOCAL's WARNING. The author hasproposed a different feature to improve the coverage by adding similarmeta-commands to psql where error messages could be checked, somethingmore useful for the cases where commands cannot be used in transactionblocks, like REINDEX CONCURRENTLY or VACUUM. This is considered asfuture work for v18~.Author: Anthonin BonnefoyReviewed-by: Jelte Fennema-Nio, Michael PaquierDiscussion:https://postgr.es/m/CAO6_XqrWO8uNBQrSu5r6jh+vTGi5Oiyk4y8yXDORdE2jbzw8xw@mail.gmail.comBackpatch-through: 13
1 parent48a6cd1 commit5c30672

File tree

3 files changed

+29
-23
lines changed

3 files changed

+29
-23
lines changed

‎doc/src/sgml/protocol.sgml

Lines changed: 11 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1088,16 +1088,17 @@ SELCT 1/0;<!-- this typo is intentional -->
10881088

10891089
<para>
10901090
If the client has not issued an explicit <command>BEGIN</command>,
1091-
then each Sync ordinarily causes an implicit <command>COMMIT</command>
1092-
if the preceding step(s) succeeded, or an
1093-
implicit <command>ROLLBACK</command> if they failed. However, there
1094-
are a few DDL commands (such as <command>CREATE DATABASE</command>)
1095-
that cannot be executed inside a transaction block. If one of
1096-
these is executed in a pipeline, it will fail unless it is the first
1097-
command in the pipeline. Furthermore, upon success it will force an
1098-
immediate commit to preserve database consistency. Thus a Sync
1099-
immediately following one of these commands has no effect except to
1100-
respond with ReadyForQuery.
1091+
then an implicit transaction block is started and each Sync ordinarily
1092+
causes an implicit <command>COMMIT</command> if the preceding step(s)
1093+
succeeded, or an implicit <command>ROLLBACK</command> if they failed.
1094+
This implicit transaction block will only be detected by the server
1095+
when the first command ends without a sync. There are a few DDL
1096+
commands (such as <command>CREATE DATABASE</command>) that cannot be
1097+
executed inside a transaction block. If one of these is executed in a
1098+
pipeline, it will fail unless it is the first command after a Sync.
1099+
Furthermore, upon success it will force an immediate commit to preserve
1100+
database consistency. Thus a Sync immediately following one of these
1101+
commands has no effect except to respond with ReadyForQuery.
11011102
</para>
11021103

11031104
<para>

‎src/backend/access/transam/xact.c

Lines changed: 0 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -3405,16 +3405,6 @@ PreventInTransactionBlock(bool isTopLevel, const char *stmtType)
34053405
errmsg("%s cannot run inside a subtransaction",
34063406
stmtType)));
34073407

3408-
/*
3409-
* inside a pipeline that has started an implicit transaction?
3410-
*/
3411-
if (MyXactFlags&XACT_FLAGS_PIPELINING)
3412-
ereport(ERROR,
3413-
(errcode(ERRCODE_ACTIVE_SQL_TRANSACTION),
3414-
/* translator: %s represents an SQL statement name */
3415-
errmsg("%s cannot be executed within a pipeline",
3416-
stmtType)));
3417-
34183408
/*
34193409
* inside a function call?
34203410
*/
@@ -3526,9 +3516,6 @@ IsInTransactionBlock(bool isTopLevel)
35263516
if (IsSubTransaction())
35273517
return true;
35283518

3529-
if (MyXactFlags&XACT_FLAGS_PIPELINING)
3530-
return true;
3531-
35323519
if (!isTopLevel)
35333520
return true;
35343521

‎src/backend/tcop/postgres.c

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2656,6 +2656,17 @@ start_xact_command(void)
26562656

26572657
xact_started= true;
26582658
}
2659+
elseif (MyXactFlags&XACT_FLAGS_PIPELINING)
2660+
{
2661+
/*
2662+
* When the first Execute message is completed, following commands
2663+
* will be done in an implicit transaction block created via
2664+
* pipelining. The transaction state needs to be updated to an
2665+
* implicit block if we're not already in a transaction block (like
2666+
* one started by an explicit BEGIN).
2667+
*/
2668+
BeginImplicitTransactionBlock();
2669+
}
26592670

26602671
/*
26612672
* Start statement timeout if necessary. Note that this'll intentionally
@@ -4605,6 +4616,13 @@ PostgresMain(int argc, char *argv[],
46054616

46064617
case'S':/* sync */
46074618
pq_getmsgend(&input_message);
4619+
4620+
/*
4621+
* If pipelining was used, we may be in an implicit
4622+
* transaction block. Close it before calling
4623+
* finish_xact_command.
4624+
*/
4625+
EndImplicitTransactionBlock();
46084626
finish_xact_command();
46094627
send_ready_for_query= true;
46104628
break;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp