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.GK17695@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,
configreload, 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
willbe 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
fromapplication.
>> 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