On Wed, Jun 29, 2016 at 11:18 PM, Michael Paquier <michael.paqu...@gmail.com > wrote:
> On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera > <alvhe...@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. > There was also that (old) thread about making the recovery.conf parameters be general GUCs. I don't actually remember the consensus there, but diong that would certainly change how it's handled as well. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
