Horton

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

Yugo Nagata <nagata@sraoss.co.jp>

View thread View on postgr.es
From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, "David G. Johnston" <david.g.johnston@gmail.com>, Bruce Momjian <bruce@momjian.us>
Date: 2022-11-10T04:49:19Z
Lists: pgsql-bugs, pgsql-hackers 
On Wed, 09 Nov 2022 11:17:29 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Yugo NAGATA <nagata@sraoss.co.jp> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> What do you think of the attached wording?
> 
> > It looks good to me. That describes the expected behaviour exactly.
> 
> Pushed that, then.

Thank you.

> >> I don't think the pipeline angle is of concern to anyone who might be
> >> reading these comments with the aim of understanding what guarantees
> >> they have.  Perhaps there should be more about that in the user-facing
> >> docs, though.
> 
> > I agree with that we don't need to mention pipelining in these comments,
> > and that we need more in the documentation. I attached a doc patch to add
> > a mention of commands that do internal commit to the pipelining section.
> > Also, this adds a reference for the pipelining protocol to the libpq doc.
> 
> Hmm ... I don't really find either of these changes to be improvements.
> The fact that, say, multi-table ANALYZE uses multiple transactions
> seems to me to be a property of that statement, not of the protocol.

Ok. Then, if we want to notice users that commands using internal commits
could unexpectedly close a transaction in pipelining, the proper place is
libpq section?

Regards,
Yugo Nagata

-- 
Yugo NAGATA <nagata@sraoss.co.jp>

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.