• Tom Lane's avatar
    Fix handling of -d "connection string" in pg_dump/pg_restore. · a45bc8a4
    Tom Lane authored
    Parallel pg_dump failed if its -d parameter was a connection string
    containing any essential information other than host, port, or username.
    The same was true for pg_restore with --create.
    
    The reason is that these scenarios failed to preserve the connection
    string from the command line; the code felt free to replace that with
    just the database name when reconnecting from a pg_dump parallel worker
    or after creating the target database.  By chance, parallel pg_restore
    did not suffer this defect, as long as you didn't say --create.
    
    In practice it seems that the error would be obvious only if the
    connstring included essential, non-default SSL or GSS parameters.
    This may explain why it took us so long to notice.  (It also makes
    it very difficult to craft a regression test case illustrating the
    problem, since the test would fail in builds without those options.)
    
    Fix by refactoring so that ConnectDatabase always receives all the
    relevant options directly from the command line, rather than
    reconstructed values.  Inject a different database name, when necessary,
    by relying on libpq's rules for handling multiple "dbname" parameters.
    
    While here, let's get rid of the essentially duplicate _connectDB
    function, as well as some obsolete nearby cruft.
    
    Per bug #16604 from Zsolt Ero.  Back-patch to all supported branches.
    
    Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org
    a45bc8a4
pg_backup.h 8.36 KB