Re: primary_conninfo missing from pg_stat_wal_receiver

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: 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-24 08:46:16
Message-ID: CAB7nPqScFyFQ3cbpMm+OPe5_z8HmJGHCQ-o2+6HQMEDk1j8waQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 22, 2016 at 10:51 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> This connection string is stored in shared memory in WalRcvData, and
> that's the case for a couple of releases now, so it has already a high
> footprint, though I agree that making that available at SQL level
> makes it even worse. Looking at the code, as libpq does not link
> directly to libpqcommon, I think that the cleanest solution is to do
> something similar to wchar.c, aka split the parsing, deparsing
> routines that we are going to use in a file located in src/backend/,
> and then build libpq using it. Writing a patch for that would not be
> that complicated. What is stored in WalRcvData is then the connection
> string filtered of its password field, or we could just obfuscate it
> with ***. It may still be useful to the user to know that a password
> has been used.

I have been thinking more about that, and came up with the following
idea... We do not want to link libpq directly to the server, so let's
add a new routine to libpqwalreceiver that builds an obfuscated
connection string and let's have walreceiver.c save it in shared
memory. Then pg_stat_wal_receiver just makes use of this string. This
results in a rather light patch, proposed as attached. Connection URIs
get as well translated as connection strings via PQconninfo(), then
the new interface routine of libpqwalreceiver looks at dispchar to
determine if it should dump a field or not and obfuscates it with more
or less '****'.

Thoughts?
--
Michael

Attachment Content-Type Size
wal-receiver-conninfo-v3.patch invalid/octet-stream 9.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mithun Cy 2016-06-24 09:08:34 Re: Hash Indexes
Previous Message Ashutosh Bapat 2016-06-24 08:38:20 Re: Postgres_fdw join pushdown - wrong results with whole-row reference