From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Alex Shulgin <ash(at)commandprompt(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Replication connection URI? |
Date: | 2014-11-25 15:11:36 |
Message-ID: | 54749C28.5080709@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/24/2014 06:05 PM, Alex Shulgin wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-11-25 15:23:22 | Re: tracking commit timestamps |
Previous Message | Stephen Frost | 2014-11-25 15:10:24 | Re: Transient failure of rowsecurity regression test |