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 f25c50fd8f
commit 3c5d9d914f

View File

@@ -3550,14 +3550,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);
}
/*