Re: primary_conninfo missing from pg_stat_wal_receiver

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, 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 Fearing <vik(at)2ndquadrant(dot)fr>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: primary_conninfo missing from pg_stat_wal_receiver
Date: 2016-07-07 18:11:12
Message-ID: CA+Tgmoam_quHMBZJBi4yTvgr9qsAAXhk6WZULeOkta2rnO2Gsg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 30, 2016 at 10:24 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Also, actually, I see no reason for the conninfo to be shown differently
> regardless of a connection being already established. If we show the
> conninfo that the server is trying to use, it might be easier to
> diagnose a problem. In short, I think this is all misconceived (mea
> culpa) and that we should have two conninfo members in that struct as
> initially proposed, one obfuscated and the other not.

Seriously!

The whole problem here is being created by trying to use the same
field for two different purposes:

1. The string that should actually be used for connections.
2. The sanitized version that should be exposed to the user.

If you try to use the same variable to store two different values,
both bugs and confusion may result.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-07-07 18:21:08 Re: Reviewing freeze map code
Previous Message Simon Riggs 2016-07-07 18:10:51 Re: MVCC overheads