Re: Failed transaction statistics to measure the logical replication progress - Mailing list pgsql-hackers

From Ajin Cherian
Subject Re: Failed transaction statistics to measure the logical replication progress
Date
Msg-id CAFPTHDZUXvW2CTQKTdLTnPrGgJWACcy-aMYXT6j1vuL=zq8k1A@mail.gmail.com
Whole thread Raw
In response to Failed transaction statistics to measure the logical replication progress  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses RE: Failed transaction statistics to measure the logical replication progress  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Some code cleanup for pgbench and pg_verifybackup
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Minimal logical decoding on standbys