Re: allow online change primary_conninfo
От | Sergei Kornilov |
---|---|
Тема | Re: allow online change primary_conninfo |
Дата | |
Msg-id | 4926831544698308@iva3-294f9af87d55.qloud-c.yandex.net обсуждение исходный текст |
Ответ на | Re: allow online change primary_conninfo (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: allow online change primary_conninfo
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: