Re: Replication connection URI? - Mailing list pgsql-hackers
From | Heikki Linnakangas |
---|---|
Subject | Re: Replication connection URI? |
Date | |
Msg-id | 5474AEC9.2070109@vmware.com Whole thread Raw |
In response to | Re: Replication connection URI? (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Responses |
Re: Replication connection URI?
Re: Replication connection URI? |
List | pgsql-hackers |
On 11/25/2014 05:11 PM, Heikki Linnakangas wrote: > 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. Ok, committed the second patch to all stable branches, and the third patch to master. In the second patch, I added a sentence to the docs to mention that only the first "dbname" parameter is expanded. It's debatable if that's what we actually want. It would be handy to be able to merge multiple connection strings, by specifying multiple dbname parameters. But now the docs at least match the code, changing the behavior would be a bigger change. From the third patch, I removed the docs changes. It's necessary to say "connection string or URI" everywhere, the URI format is just one kind of a connection string. I also edited the code that builds the keyword/value array, to make it a bit more readable. - Heikki
pgsql-hackers by date: