agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedBUG #19718: pg_dump -Ft: restore.sql gets "\unrestrict (null)"/"\restrict (null)", so psql skips \i data files
2+ messages / 2 participants
[nested] [flat]
* BUG #19718: pg_dump -Ft: restore.sql gets "\unrestrict (null)"/"\restrict (null)", so psql skips \i data files
@ 2026-09-24 21:24 PG Bug reporting form <noreply@postgresql.org>
2026-09-26 16:40 ` Re: BUG #19718: pg_dump -Ft: restore.sql gets "\unrestrict (null)"/"\restrict (null)", so psql skips \i data files Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2026-09-24 21:24 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: pkopylov@cloudlinux.com
The following bug has been logged on the website:
Bug reference: 19718
Logged by: Pavel Kopylov
Email address: pkopylov@cloudlinux.com
PostgreSQL version: 17.11
Operating system: Debian 13
Description:
Since commit 71ea0d6795 ("Restrict psql meta-commands in plain-text dumps"),
```c
_reconnectToDB() in src/bin/pg_dump/pg_backup_archiver.c writes
ahprintf(AH, "\\unrestrict %s\n", ropt->restrict_key);
...
ahprintf(AH, "\\restrict %s\n\n", ropt->restrict_key);
```
without checking ropt->restrict_key.
RestoreArchive() emits the same markers only "if (ropt->restrict_key)".
pg_dump generates a restrict key only for --format=plain. The tar format,
however, still writes a plain-text restore.sql through RestoreArchive() in
_CloseArchive() (pg_backup_tar.c), using a copy of the dump's
RestoreOptions, where restrict_key is NULL. pg_dump always sets
outputCreateDB for non-plain formats, so the DATABASE TOC entry always
reaches _reconnectToDB(), and every tar-format restore.sql contains:
```
\unrestrict (null)
\connect srcdb
\restrict (null)
```
When the script is run with "psql -f restore.sql", the first line fails
with "\unrestrict: not currently in restricted mode". psql then enters
restricted mode with the key "(null)" and rejects every later
meta-command. With pg_dump -Ft --inserts the table data is loaded through
"\i $$PATH$$/NNNN.dat", so no table data is restored at all.
Reproduced on 18.6 and 17.11 (official Docker images).
The code on master is the same.
The logged output run on the official Docker image is:
```
$ cat repro-debian13.log
### Debian GNU/Linux 13 (trixie), postgresql-15-pllua postgresql-17
17.11-0+deb13u1postgresql-17-jit-llvm postgresql-17-pllua postgresql-9.1
+ createdb srcdb
+ psql -Xq srcdb -c 'CREATE TABLE t(i int); INSERT INTO t SELECT
generate_series(1,10)'
+ mkdir /tmp/x
+ cd /tmp/x
+ pg_dump -Ft --inserts srcdb -f d.tar
+ tar xf d.tar
+ sed -i 's|[$][$]PATH[$][$]|/tmp/x|g' restore.sql
+ dropdb srcdb
+ createdb srcdb
+ psql -X -d srcdb -f restore.sql
+ grep -i restrict
psql:restore.sql:37: error: \unrestrict: not currently in restricted mode
psql:restore.sql:72: error: backslash commands are restricted; only
\unrestrict is allowed
+ psql -XAt -d srcdb -c 'SELECT count(*) FROM t'
0
```
The expected output number MUST be 10 instead of 0.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #19718: pg_dump -Ft: restore.sql gets "\unrestrict (null)"/"\restrict (null)", so psql skips \i data files
2026-09-24 21:24 BUG #19718: pg_dump -Ft: restore.sql gets "\unrestrict (null)"/"\restrict (null)", so psql skips \i data files PG Bug reporting form <noreply@postgresql.org>
@ 2026-09-26 16:40 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2026-09-26 16:40 UTC (permalink / raw)
To: pkopylov@cloudlinux.com; +Cc: pgsql-bugs@lists.postgresql.org, Nathan Bossart <nathandbossart@gmail.com>
PG Bug reporting form <noreply@postgresql.org> writes:
> Since commit 71ea0d6795 ("Restrict psql meta-commands in plain-text dumps"),
> _reconnectToDB() in src/bin/pg_dump/pg_backup_archiver.c writes
> ahprintf(AH, "\\unrestrict %s\n", ropt->restrict_key);
> ...
> ahprintf(AH, "\\restrict %s\n\n", ropt->restrict_key);
> without checking ropt->restrict_key.
Yeah, that's bad. It's not surprising that nobody noticed for
tar-format "restore.sql" files, because those are pretty much
write-only; I don't know of any tool that uses them. I wonder
though if there's any other way to reach this ...
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-09-26 16:40 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-24 21:24 BUG #19718: pg_dump -Ft: restore.sql gets "\unrestrict (null)"/"\restrict (null)", so psql skips \i data files PG Bug reporting form <noreply@postgresql.org>
2026-09-26 16:40 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox