Re: primary_conninfo missing from pg_stat_wal_receiver - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: primary_conninfo missing from pg_stat_wal_receiver
Date
Msg-id CAB7nPqQF8ROkZCeA9DfD8vym5TeQHMzSmmLjjD4e_U=-V8s67g@mail.gmail.com
Whole thread Raw
In response to Re: primary_conninfo missing from pg_stat_wal_receiver  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Michael Paquier wrote:
>> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>
>> > I have already edited the patch following some of these ideas.  Will
>> > post a new version later.
>>
>> Cool, thanks.
>
> Here it is.  I found it was annoying to maintain the function return
> tupdesc in two places (pg_proc.h and the function code itself), so I
> changed that too.

This looks globally fine to me. Good catch to handle NULL results of
walrcv_get_conninfo.

+       appendPQExpBuffer(&buf, "%s=%s ",
+                         conn_opt->keyword,
+                         obfuscate ? "********" : conn_opt->val)
This would add an extra space at the end of the string
unconditionally. What about checking if buf->len == 0, then fill buf
with "%s=%s", and " %s=%s" otherwise?

Do we want to do something for back-branches regarding the presence of
the connection string in shared memory? The only invasive point is the
addition of the interface routine to get back the obfuscated
connection string from libpqwalreceiver. That's a private interface in
the backend, but perhaps it would be a problem to change that in a
minor release?
-- 
Michael



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: How to kill a Background worker and Its metadata
Next
From: Kouhei Kaigai
Date:
Subject: make clean didn't clean up files generated from *.(y|l)