On Sat, Nov 2, 2024 at 4:11 AM Michael Paquier <mich...@paquier.xyz> wrote: > Now, here is a fancy case: SAVEPOINT and its two brothers. An error > would be reported on HEAD if attempting a SAVEPOINT, complaining that > we are not in a transaction block. The patch causes a different, more > confusing, failure: > FATAL: DefineSavepoint: unexpected state STARTED > > This is a bit user-unfriendly. I am not sure to see the point of > supporting savepoints in this context, so perhaps we should just issue > a cleaner error when we are under a XACT_FLAGS_PIPELINING? Reporting > that we are not in a transaction block, while, well, we are in an > implicit transaction block because of the use of pipelines is > confusing. The new error is actually worse.
There's a possible alternative approach. Instead of checking the XACT_FLAGS_PIPELINING flag in CheckTransactionBlock/IsInTransactionBlock/PreventInTransactionBlock, it is possible to switch the transaction state to TBLOCK_IMPLICIT_INPROGRESS by reusing BeginImplicitTransactionBlock. This transaction state is used to represent a transaction block created by a multi statement query which is executed within the same transaction, which is very similar to what's done with pipelining. This allows the removal of the XACT_FLAGS_PIPELINING check in IsInTransactionBlock and PreventInTransactionBlock since the transaction state will correctly reflect the ongoing implicit block. Additionally, it will reuse the same behaviour with regard to SAVEPOINT and disallow them with a "SAVEPOINT can only be used in transaction blocks" error.
v02-0001-Consider-pipeline-implicit-transaction-as-a-tran.patch
Description: Binary data
