1
0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00

Don't emit garbage "\[un]restrict (null)" commands in pg_dump.

_reconnectToDB() failed to consider the possibility that it could
be called without any restrict_key set.  This is reachable while
generating the "restore.sql" file in tar dump mode, which nobody
noticed because that file is mostly unused (and nothing really
bad happens anyway unless you specified --inserts mode).  But
I wonder if there are other code paths that reach the issue.

Bug: #19718
Reported-by: Pavel Kopylov <pkopylov@cloudlinux.com>
Author: Pavel Kopylov <pkopylov@cloudlinux.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19718-7e945d0ff9b5a589@postgresql.org
Backpatch-through: 14
This commit is contained in:
Tom Lane
2026-09-26 12:55:40 -04:00
parent 753057e340
commit 2d748cfe33

View File

@@ -3540,14 +3540,16 @@ _reconnectToDB(ArchiveHandle *AH, const char *dbname)
* Anything added between this line and the following \restrict must
* be careful to avoid any possible meta-command injection vectors.
*/
ahprintf(AH, "\\unrestrict %s\n", ropt->restrict_key);
if (ropt->restrict_key)
ahprintf(AH, "\\unrestrict %s\n", ropt->restrict_key);
initPQExpBuffer(&connectbuf);
appendPsqlMetaConnect(&connectbuf, dbname);
ahprintf(AH, "%s", connectbuf.data);
termPQExpBuffer(&connectbuf);
ahprintf(AH, "\\restrict %s\n\n", ropt->restrict_key);
if (ropt->restrict_key)
ahprintf(AH, "\\restrict %s\n\n", ropt->restrict_key);
}
/*