On Wed, Jun 22, 2016 at 10:51 AM, Michael Paquier
<michael.paquier@gmail.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
