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?  (Alex Shulgin <ash@commandprompt.com>)
Re: Replication connection URI?  (Oleksandr Shulgin <oleksandr.shulgin@zalando.de>)
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:

Previous
From: Petr Jelinek
Date:
Subject: Re: tracking commit timestamps
Next
From: Simon Riggs
Date:
Subject: Re: tracking commit timestamps