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

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Yugo Nagata <nagata@sraoss.co.jp>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-07-26T15:22:38Z
Lists: pgsql-bugs, pgsql-hackers
On Tue, Jul 26, 2022 at 8:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > I guess I am expecting exec_execute_message to have:
>
> > if (completed && use_implicit_block)
> > {
> >     EndImplicitTransactionBlock();
> >     finish_xact_command();
> > } else if (completed) [existing code continues]
>
> The problem with that is "where do we get use_implicit_block from"?
> In simple query mode it's set if the simple-query message contains
> more than one statement.  But the issue we face in extended mode is
> precisely that we don't know if the client will try to send another
> statement before Sync.
> [...]
> Anyway, here's an updated patch, now with docs.  I was surprised
> to realize that protocol.sgml has no explicit mention of pipelining,
> even though extended query protocol was intentionally set up to make
> that possible.  So I added a <sect2> about that, which provides a home
> for the caveat about immediate-commit commands.
>
>
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.

David J.

Commits

  1. Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode.

  2. Doc: add comments about PreventInTransactionBlock/IsInTransactionBlock.

  3. Force immediate commit after CREATE DATABASE etc in extended protocol.