Re: primary_conninfo missing from pg_stat_wal_receiver

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: primary_conninfo missing from pg_stat_wal_receiver
Дата
Msg-id CAB7nPqQF8ROkZCeA9DfD8vym5TeQHMzSmmLjjD4e_U=-V8s67g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: primary_conninfo missing from pg_stat_wal_receiver  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: How to kill a Background worker and Its metadata
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: make clean didn't clean up files generated from *.(y|l)