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 по дате отправления: