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

From Alex Shulgin
Subject Re: Replication connection URI?
Date
Msg-id 87tx1or3cc.fsf@commandprompt.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>)
Missing OOM checks in libpq (was Re: Replication connection URI?)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Re: Replication connection URI?  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
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.

Have a nice day!
--
Alex


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_class(relpersistence) of hash index
Next
From: David G Johnston
Date:
Subject: Re: Turning recovery.conf into GUCs