Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
Date: 2022-07-28 02:50:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> writes:
> I've looked at the commited fix. What I wonder is whether a change in
> IsInTransactionBlock() is necessary or not.

I've not examined ANALYZE's dependencies on this closely, but it doesn't
matter really, because I'm not willing to assume that ANALYZE is the
only caller. There could be external modules with stronger assumptions
that IsInTransactionBlock() yielding false provides guarantees equivalent
to PreventInTransactionBlock(). It did before this patch, so I think
it needs to still do so after.

> In fact, the result of IsInTransactionBlock does not make senses at
> all in pipe-line mode regardless to the fix. ANALYZE could commit all
> previous commands in pipelining, and this may not be user expected
> behaviour.

This seems pretty much isomorphic to the fact that CREATE DATABASE
will commit preceding steps in the pipeline. That's not great,
I admit; we'd not have designed it like that if we'd had complete
understanding of the behavior at the beginning. But it's acted
like that for a couple of decades now, so changing it seems far
more likely to make people unhappy than happy. The same for
ANALYZE in a pipeline.

> If the first command in a pipeline is DDL commands such as CREATE
> DATABASE, this is allowed and immediately committed after success, as
> same as the current behavior. Executing such commands in the middle of
> pipeline is not allowed because the pipeline is regarded as "an implicit
> transaction block" at that time. Similarly, ANALYZE in the middle of
> pipeline can not close and open transaction.

I'm not going there. If you can persuade some other committer that
this is worth breaking backward compatibility for, fine; the user
complaints will be their problem.

regards, tom lane

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Langote 2022-07-28 04:11:32 Re: BUG #16754: When using LLVM and parallel queries aborted all session by pg_cancel_backend.
Previous Message Peter Smith 2022-07-28 01:55:51 Re: Excessive number of replication slots for 12->14 logical replication

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-28 02:57:15 Re: Official Windows Installer and Documentation
Previous Message 2022-07-28 02:50:15 RE: Support load balancing in libpq