Re: Replication connection URI?

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 16:31:05
Message-ID: 5474AEC9.2070109@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-11-25 16:51:23 Re: tracking commit timestamps
Previous Message Petr Jelinek 2014-11-25 16:18:35 Re: tracking commit timestamps