Re: primary_conninfo missing from pg_stat_wal_receiver
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, Tatsuo Ishii <ishii@postgresql.org>, Vik Fearing <vik@2ndquadrant.fr>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2016-06-29T21:18:49Z
Lists: pgsql-hackers
On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Alvaro Herrera wrote: > >> I propose to push this patch, closing the open item, and you can rework >> on top -- I suppose you would completely remove the original conninfo >> from shared memory and instead only copy the obfuscated version there >> (and probably also remove the ready_to_display flag). I think we'd need >> to see the patch before deciding whether we want it in 9.6 or not, >> keeping in mind that having the conninfo in shared memory is a >> pre-existing problem, unrelated to the pgstats view new in 9.6. > > Pushed this. Feel free to tinker further with it, if you feel the need > to. > > Regarding backpatching the clearing of shared memory, I'm inclined not > to. If there is a real security concern there (I'm unsure what attack > are we protecting against), it may be better fixed by the approach > suggested by Fujii whereby the sensitive info is not ever published in > shared memory. Yes, this is not going to be pretty invasive anyway. The cleanest way to handle things here would be to refactor a bit xlog.c (xlogparams.c?) so as readRecoveryCommandFile is exposed in its own file, and the recovery parameters are handled in a single structure, which is the return result of the call. To reduce a bit the cruft in xlog.c that would be nice anyway I guess. -- Michael
Commits
-
Add conninfo to pg_stat_wal_receiver
- 9ed551e0a4fd 9.6.0 landed
-
Only show pg_stat_replication details to superusers
- f88a638199d8 9.1.0 cited