Re: Set AUTOCOMMIT to on in script output by pg_dump
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Yugo Nagata <nagata@sraoss.co.jp>
Cc: Shinya Kato <Shinya11.Kato@oss.nttdata.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-10-09T03:53:15Z
Lists: pgsql-hackers
On Tuesday, October 8, 2024, Yugo Nagata <nagata@sraoss.co.jp> wrote: > On Wed, 09 Oct 2024 11:10:37 +0900 > Shinya Kato <Shinya11.Kato@oss.nttdata.com> wrote: > > > Hi hackers! > > > > When SQL scripts created with pg_dump/pg_dumpall/pg_restore are executed > > in psql with AUTOCOMMIT turned off, they will not succeed in many cases. > > This is because the script contains SQL statements that cannot be > > executed within a transaction block. > > > > If you simply add set AUTOCOMMIT on to the scripts created by > > pg_dump/pg_dumpall/pg_restore, they will work fine. > > A patch is attached > > > > I am not sure if it is good to include psql's meta-command in > pg_dump/pg_dumpall > results. Can we assume users will always use psql to restore the pg_dump > results? Agreed. If we aren’t already outputting psql-only stuff I am a strong -1 for making this the first such case. It would be nice to describe exactly when there is a problem as well since very few things require being outside of a transaction. There might be documentation or code patches possible here to improve matters (like adding a switch to output begin/commit in the places we’re a user might want single-transaction behavior) but this approach breaks well-established encapsulation and overrides user expectations in a bad way (since autocommit=on is the default they choose to turn it off so turning it back on silently - not even documented - is bad.) David J.
Commits
-
Doc: recommend "psql -X" for restoring pg_dump scripts.
- d83a108c10a3 18.0 landed
- c768f54a25a4 15.11 landed
- aaa0f061936a 13.19 landed
- 76601c0c885a 17.3 landed
- 53771e44df81 16.7 landed
- 4106942f004f 14.16 landed