Re: primary_conninfo missing from pg_stat_wal_receiver

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, vik(at)2ndquadrant(dot)fr, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Masao Fujii <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: primary_conninfo missing from pg_stat_wal_receiver
Date: 2016-06-29 03:53:17
Message-ID: CAB7nPqQF8ROkZCeA9DfD8vym5TeQHMzSmmLjjD4e_U=-V8s67g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Michael Paquier wrote:
>> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2016-06-29 04:24:58 make clean didn't clean up files generated from *.(y|l)
Previous Message Craig Ringer 2016-06-29 03:52:33 Re: How to kill a Background worker and Its metadata