| From: | Alex Shulgin <ash(at)commandprompt(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Replication connection URI? |
| Date: | 2014-11-24 16:05:39 |
| Message-ID: | 87tx1or3cc.fsf@commandprompt.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Have a nice day!
--
Alex
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-missing-check-on-OOM-in-expand_dbname-path-of-co.patch | text/x-diff | 1.0 KB |
| 0002-Allow-further-dbname-value-to-override-conninfo-pars.patch | text/x-diff | 2.8 KB |
| 0003-Allow-URI-in-primary_conninfo-line-of-recovery.conf-.patch | text/x-diff | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2014-11-24 16:50:00 | Re: superuser() shortcuts |
| Previous Message | Tom Lane | 2014-11-24 15:48:00 | Re: pg_class(relpersistence) of hash index |