From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Bruce Momjian <bruce@momjian.us>, Yugo Nagata <nagata@sraoss.co.jp>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same
 transaction with other commands
In-reply-to: 
 <CAKFQuwYRYhF8iOD9MHp7VuZur_JvVEjDzpMHuUHNeYReB5v2Sw@mail.gmail.com>
References: <17434-d9f7a064ce2a88a3@postgresql.org>
 <YtCrjN0HLew0w4Ss@momjian.us> <3190751.1657845414@sss.pgh.pa.us>
 <CAKFQuwbY_vJWcvJLUz2r+zzwwhkJbjzjojfGx=Mvd9TZ0TTKew@mail.gmail.com>
 <3498921.1657919211@sss.pgh.pa.us>
 <CAKFQuwa9JQgKgg3Djrx=7p1Phhj68QEq0TWYG72Xv-nPz61r0w@mail.gmail.com>
 <805866.1658175624@sss.pgh.pa.us>
 <CAKFQuwYQpm6E4nTgiOZAGRg0JKquHaXQ0JkqruWeHuOQX6-70g@mail.gmail.com>
 <2350990.1658848101@sss.pgh.pa.us>
 <CAKFQuwYRYhF8iOD9MHp7VuZur_JvVEjDzpMHuUHNeYReB5v2Sw@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Tue, 26 Jul 2022 08:22:38 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2356215.1658849834.1@sss.pgh.pa.us>
Date: Tue, 26 Jul 2022 11:37:14 -0400
Message-ID: <2356216.1658849834@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2356216.1658849834%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Thanks!  This added section is clear and now affirms the understanding I've
> come to with this thread, mostly.  I'm still of the opinion that the
> definition of "cannot be executed inside a transaction block" means that we
> must "auto-sync" (implicit commit) before and after the restricted command,
> not just after, and that the new section should cover this - whether we do
> or do not - explicitly.

I'm not excited about your proposal to auto-commit before starting
the command.  In the first place, we can't: we do not know whether
the command will call PreventInTransactionBlock.  Restructuring to
change that seems untenable in view of past cowboy decisions about
use of PreventInTransactionBlock in the replication logic.  In the
second place, it'd be a deviation from the current behavior (namely
that a failure in CREATE DATABASE et al rolls back previous un-synced
commands) that is not necessary to fix a bug, so changing that in
the back branches would be a hard sell.  I don't even agree that
it's obviously better than the current behavior, so I'm not much
on board with changing it in HEAD either.

			regards, tom lane