Horton

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

Israel Barth Rubio <barthisrael@gmail.com>

View thread View on postgr.es
From: Israel Barth Rubio <barthisrael@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yugo NAGATA <nagata@sraoss.co.jp>, 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-25T15:17:02Z
Lists: pgsql-bugs, pgsql-hackers 
> Attached is a draft patch along the lines I speculated about above.
> It breaks backwards compatibility in that PreventInTransactionBlock
> commands will now be rejected if they're a non-first command in a
> pipeline.  I think that's okay, and arguably desirable, for HEAD
> but I'm pretty uncomfortable about back-patching it.

I attempted to run these using HEAD, and it fails:

    parse: create temporary table t1 (a int) on commit drop
    bind
    execute
    parse: analyze t1
    bind
    execute
    parse: select * from t1
    bind
    execute
    sync

It then works fine after applying your patch!

Just for some context, this was brought by Peter E. based on an issue
reported by a customer. They are using PostgreSQL 11, and the issue
was observed after upgrading to PostgreSQL 11.17, which includes the
commit 9e3e1ac458abcda5aa03fa2a136e6fa492d58bd6. As a workaround
they downgraded the binaries to 11.16.

It would be great if we can back-patch this to all supported versions,
as the issue itself is currently affecting them all.

Regards,
Israel.

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.