On Thu, Dec 13, 2018 at 01:51:48PM +0300, Sergei Kornilov wrote: > Depends on this discussion: > https://www.postgresql.org/message-id/20181212053042.gk17...@paquier.xyz > If walreceiver will use GUC conninfo for startup - then yes, we can > remove such static variables. If walreceiver will still use conninfo > from WalRcv - we have race condition between RequestXLogStreaming from > startup, config reload, and walreceiver start. In this case I need > save conninfo from WalRcv and compare new GUC value with them.
I would recommend waiting for the conclusion of other thread before moving on with this one. There are arguments for letting the startup process deciding which connection string the WAL receiver should use as well as letting the WAL receiver use directly the connection string from the GUC. > Hmm. We have infrastructure to hide such values? > I need implement something like flag GUC_HIDE_VALUE_FROM_LOG near > GUC_SUPERUSER_ONLY in separate thread? Log message will be changed to > "LOG: parameter "primary_conninfo" changed" with this flag. Good point. Passwords in logs can be considered as a security issue. Having such an option may be interesting for other things, though I am not sure if just having an option to hide logs related to a given parameter are the correct way to shape it. We could also consider using the show hook function of a parameter to print its value in such logs. -- Michael
signature.asc
Description: PGP signature
