On Wed, Jun 22, 2016 at 10:51 AM, Michael Paquier <michael.paqu...@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
wal-receiver-conninfo-v3.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
