Horton

Re: BUG #16604: pg_dump with --jobs breaks SSL connections

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zsolt Ero <zsolt.ero@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2020-09-24T16:11:36Z
Lists: pgsql-bugs 
Zsolt Ero <zsolt.ero@gmail.com> writes:
>  I've created a minimal reproducible Dockerfile, it reproduces 100%. The PG
> server is configured to require client certificates.

I reproduced this locally, and the problem seems to be that
CloneArchive() is doing a far-less-than-half-baked job of
reconstructing the original connection parameters.
The data that PQconnectdbParams gets is just

(gdb) p keywords
$1 = {0x44ef22 "host", 0x44d52d "port", 0x44e4f0 "user", 0x4532b6 "password", 
  0x44ef14 "dbname", 0x45325f "fallback_application_name", 0x0}
(gdb) p values
$2 = {0x25459e0 "127.0.0.1", 0x25459a0 "5432", 0x2545180 "postgres", 0x0, 
  0x2a61d60 "dbname=regression", 0x2538410 "pg_dump", 0x0}

so parallel pg_dump is basically guaranteed to fail in any
case with even slightly unusual connection parameters.

Not sure why we should be trying to do it like that at
all; it'd be better if the original command-line parameters
got passed down in all cases.  Looking at that now.

			regards, tom lane

Commits

  1. Fix connection string handling in psql's \connect command.

  2. Fix connection string handling in src/bin/scripts/ programs.

  3. Fix handling of -d "connection string" in pg_dump/pg_restore.