Re: Consider pipeline implicit transaction as a transaction block

On Sat, Nov 2, 2024 at 4:11 AM Michael Paquier <michael(at)paquier(dot)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.