Hello > Do we no longer need static version of conninfo/slotname in > walreceiver.c? We can detect a change of the variables without > them (as you did in the previous version.).
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 don't think it is acceptable that raw conninfo is exposed into > log file. > >> LOG: parameter "primary_conninfo" changed to "host=/tmp port=5432 >> password=hoge" 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. I also think that this is not a big problem. We may already have secret data in the logs. For example, in query text from application. >> errmsg("closing replication connection because primary_conninfo was >> changed"))); > > Maybe it is better being as follows according to similar messages: > >> errmsg("terminating walreceiver process due to change of >> primary_conninfo"))); > > And it *might* be good to have detail. > >> errdetail("In a moment starts streaming WAL with new configuration."); Agreed, will change. regards, Sergei
