Re: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline"
От | Tom Lane |
---|---|
Тема | Re: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline" |
Дата | |
Msg-id | 841565.1677254194@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline" (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline"
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: