From: Tom Lane <tgl@sss.pgh.pa.us>
To: wesley.smith@zapproved.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be
 executed within a pipeline"
In-reply-to: <17806-8ae970739d661c0b@postgresql.org>
References: <17806-8ae970739d661c0b@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 23 Feb 2023 22:33:30 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <841564.1677254194.1@sss.pgh.pa.us>
Date: Fri, 24 Feb 2023 10:56:34 -0500
Message-ID: <841565.1677254194@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/841565.1677254194%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> I am starting up a fresh instance of Postgres inside of Docker using the
> "postgres:13.10" tag.  I'm then connecting to the database server using the
> Ppgsql library for .NET (version 6.0.8) and creating a new database like
> this:

> var str = "
>   CREATE ROLE foo WITH PASSWORD 'foo' LOGIN NOINHERIT;
>   GRANT foo TO postgres;
>   CREATE DATABASE my_db OWNER foo;
>   -- More statements here
> ";
> conn = new NpgsqlConnection(connString);
> var cmd = new NpgsqlCommand(sql, conn);
> await cmd.ExecuteNonQueryAsync();

You'd have to ask the Ppgsql authors exactly how they transmit that
to the server; but a plausible guess is that it's using what we
refer to as a pipeline, that is a series of commands transmitted
without waiting for the result of earlier commands.

> In all versions of PostgreSQL 13 before 10 (13.1 - 13.9), this works fine. 
> There is no error and the database is created as expected.
> However, with version 13.10, I get this error:

> Severity: ERROR
>   InvariantSeverity: ERROR
>   SqlState: 25001
>   MessageText: CREATE DATABASE cannot be executed within a pipeline
>   File: xact.c
>   Line: 3412
>   Routine: PreventInTransactionBlock

It is intended that we disallow CREATE DATABASE within a pipeline,
and has been since 13.8 et al; but we fixed some bugs in that
prohibition in 13.10.  Looking at the release-note entry about it,
that only mentions ANALYZE, which is probably my own oversight.

The motivation was to prevent semantic anomalies if one command
in the pipeline fails --- previously, you might end up with a
surprising subset of the commands having gotten committed.

			regards, tom lane