Re: Consider pipeline implicit transaction as a transaction block

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Consider pipeline implicit transaction as a transaction block
Date: 2024-11-05 05:50:06
Message-ID: ZymyDs3MrLXrSaFU@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 04, 2024 at 10:42:36AM +0100, Anthonin Bonnefoy wrote:
> 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.

Ah, interesting. I did not notice this bit in DefineSavepoint(). So
that would be the path that we would bump on for an error as
TBLOCK_IMPLICIT_INPROGRESS would not be set, based on the fact that
it does not really make sense to come back to a previous state while
we are in a pipeline.

It would be nice to document all these behaviors with regression
tests in pgbench as it is the only place where we can control that
with error pattern checks. Let's say:
- LOCK in first position of a pipeline fails, works on follow-up
commands.
- Some command not allowed in transaction blocks, like a REINDEX
CONCURRENTLY or similar?
- One part with the SET LOCAL portion of the problem, where we don't
have a hard error on the first command in this case.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2024-11-05 05:59:46 Re: define pg_structiszero(addr, s, r)
Previous Message Bertrand Drouvot 2024-11-05 05:49:22 Re: define pg_structiszero(addr, s, r)