Re: BUG #16604: pg_dump with --jobs breaks SSL connections
От | Tom Lane |
---|---|
Тема | Re: BUG #16604: pg_dump with --jobs breaks SSL connections |
Дата | |
Msg-id | 1638874.1600963896@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16604: pg_dump with --jobs breaks SSL connections (Zsolt Ero <zsolt.ero@gmail.com>) |
Ответы |
Re: BUG #16604: pg_dump with --jobs breaks SSL connections
|
Список | 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
В списке pgsql-bugs по дате отправления: