MIME-Version: 1.0
References: 
 <OSBPR01MB48887CA8F40C8D984A6DC00CED199@OSBPR01MB4888.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <OSBPR01MB48887CA8F40C8D984A6DC00CED199@OSBPR01MB4888.jpnprd01.prod.outlook.com>
From: Ajin Cherian <itsajin@gmail.com>
Date: Tue, 27 Jul 2021 16:59:14 +1000
Message-ID: 
 <CAFPTHDZUXvW2CTQKTdLTnPrGgJWACcy-aMYXT6j1vuL=zq8k1A@mail.gmail.com>
Subject: Re: Failed transaction statistics to measure the logical replication
 progress
To: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFPTHDZUXvW2CTQKTdLTnPrGgJWACcy-aMYXT6j1vuL%3Dzq8k1A%40mail.gmail.com>
Precedence: bulk

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