Re: Replication connection URI?
От | Heikki Linnakangas |
---|---|
Тема | Re: Replication connection URI? |
Дата | |
Msg-id | 54749C28.5080709@vmware.com обсуждение исходный текст |
Ответ на | Re: Replication connection URI? (Alex Shulgin <ash@commandprompt.com>) |
Ответы |
Re: Replication connection URI?
|
Список | pgsql-hackers |
On 11/24/2014 06:05 PM, Alex Shulgin wrote: > Heikki Linnakangas <hlinnakangas@vmware.com> writes: >>> >>> It appears that replication connection doesn't support URI but only the >>> traditional conninfo string. >>> >>> src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in libpqrcv_connect(): >>> >>> snprintf(conninfo_repl, sizeof(conninfo_repl), >>> "%s dbname=replication replication=true fallback_application_name=walreceiver", >>> conninfo); >>> >>> A patch to fix this welcome? >> >> Yeah, seems like an oversight. Hopefully you can fix that without >> teaching libpqwalreceiver what connection URIs look like.. > > Please see attached. We're lucky that PQconnectdbParams has an option > to parse and expand the first dbname parameter if it looks like a > connection string (or a URI). > > The first patch is not on topic, I just spotted this missing check. > > The second one is a self-contained fix, but the third one which is the > actual patch depends on the second one, because it specifies the dbname > keyword two times: first to parse the conninfo/URI, then to override any > dbname provided by the user with "replication" pseudo-database name. Hmm. Should we backpatch the second patch? It sure seems like an oversight rather than deliberate that you can't override dbname from the connection string with a later dbname keyword. I'd say "yes". How about the third patch? Probably not; it was an oversight with the connection URI patch that it could not be used in primary_conninfo, but it's not a big deal in practice as you can always use a non-URI connection string instead. - Heikki
В списке pgsql-hackers по дате отправления: