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: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers@postgresql.org, "David G. Johnston" <david.g.johnston@gmail.com>, Bruce Momjian <bruce@momjian.us>
Date: 2022-11-10T05:48:59Z
Lists: pgsql-bugs, pgsql-hackers 
On Wed, 09 Nov 2022 11:38:05 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> > This has broken the following use:
> 
> > parse: create temporary table t1 (a int) on commit drop
> > bind
> > execute
> > parse: analyze t1
> > bind
> > execute
> > parse: select * from t1
> > bind
> > execute
> > sync
> 
> > I think the behavior of IsInTransactionBlock() needs to be further 
> > refined to support this.
> 
> Hmm.  Maybe the right way to think about this is "if we have completed an
> EXECUTE, and not yet received a following SYNC, then report that we are in
> a transaction block"?  But I'm not sure if that breaks any other cases.

Or, in that case, regarding it as an implicit transaction if multiple commands
are executed in a pipeline as proposed in [1] could be another solution, 
although I have once withdrawn this for not breaking backward compatibility.
Attached is the same patch of [1].

[1] https://www.postgresql.org/message-id/20220728105134.d5ce51dd756b3149e9b9c52c%40sraoss.co.jp

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.