Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?
От | Bharath Rupireddy |
---|---|
Тема | Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData? |
Дата | |
Msg-id | CALj2ACXE_xNuwhckNzcJPUWBZcLnNadrvkTy3PTFxQvyZ1S4OQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData? (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)
|
Список | pgsql-hackers |
On Mon, Jan 10, 2022 at 6:50 AM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > On Wed, Jan 5, 2022 at 12:13 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > > Here's the v2 patch. Please provide your thoughts. > > > > Thanks! I have three comments on this version. > > Thanks for your review. > > > - I still think "acquire/release" logs on creation/dropping should be > > silenced. Adding the third parameter to ReplicationSlotAcquire() > > that can mute the acquiring (and as well as the corresponding > > releasing) log will work. > > Done. > > > can piggy-back on log_replication_commands for the purpose, changing > > its meaning slightly to "log replication commands and related > > activity". > > - Need to mute the logs by log_replication_commands. (We could add > > another choice for the variable for this purpose but I think we > > don't need it.) > > Done. > > > - The messages are not translatable as the variable parts are > > adjectives. They need to consist of static sentences. The > > combinations of the two properties are 6 (note that persistence is > > tristate) but I don't think we accept that complexity for the > > information. So I recommend to just remove the variable parts from > > the messages. > > Done. > > Here's v3, please review it further. Here's the rebased v4 patch. Regards, Bharath Rupireddy.
Вложения
В списке pgsql-hackers по дате отправления: