Re: Failed transaction statistics to measure the logical replication progress
От | Ajin Cherian |
---|---|
Тема | Re: Failed transaction statistics to measure the logical replication progress |
Дата | |
Msg-id | CAFPTHDZUXvW2CTQKTdLTnPrGgJWACcy-aMYXT6j1vuL=zq8k1A@mail.gmail.com обсуждение исходный текст |
Ответ на | Failed transaction statistics to measure the logical replication progress ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>) |
Ответы |
RE: Failed transaction statistics to measure the logical replication progress
|
Список | pgsql-hackers |
On Thu, Jul 8, 2021 at 4:55 PM osumi.takamichi@fujitsu.com <osumi.takamichi@fujitsu.com> wrote: > Attached file is the POC patch for this. > Current design is to save failed stats data in the ReplicationSlot struct. > This is because after the error, I'm not able to access the ReorderBuffer object. > Thus, I chose the object where I can interact with at the ReplicationSlotRelease timing. I think this is a good idea to capture the failed replication stats. But I'm wondering how you are deciding if the replication failed or not? Not all cases of ReplicationSLotRelease are due to a failure. It could also be due to a planned dropping of subscription or disable of subscription. I have not tested this but won't the failed stats be updated in this case as well? Is that correct? regards, Ajin Cherian Fujitsu Australia
В списке pgsql-hackers по дате отправления: