Re: Replication connection URI? - Mailing list pgsql-hackers

From Alex Shulgin
Subject Re: Replication connection URI?
Date
Msg-id 87y4qzoikd.fsf@commandprompt.com
Whole thread Raw
In response to Re: Replication connection URI?  (Alex Shulgin <ash@commandprompt.com>)
List pgsql-hackers
Alex Shulgin <ash@commandprompt.com> writes:

> 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.

These patches are really simple, I hope a committer will pick them up?
Or should I add them to the commitfest?

Also, I'd rather get this committed first, then rebase that
recovery.conf->GUC patch onto it and submit an updated version.

Thanks.
--
Alex



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Next
From: Kouhei Kaigai
Date:
Subject: Re: [v9.5] Custom Plan API