| From: | Ajin Cherian <itsajin(at)gmail(dot)com> |
|---|---|
| To: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Failed transaction statistics to measure the logical replication progress |
| Date: | 2021-07-27 06:59:14 |
| Message-ID: | CAFPTHDZUXvW2CTQKTdLTnPrGgJWACcy-aMYXT6j1vuL=zq8k1A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 8, 2021 at 4:55 PM osumi(dot)takamichi(at)fujitsu(dot)com
<osumi(dot)takamichi(at)fujitsu(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Drouvot, Bertrand | 2021-07-27 07:23:48 | Re: Minimal logical decoding on standbys |
| Previous Message | Michael Paquier | 2021-07-27 06:56:01 | Re: Some code cleanup for pgbench and pg_verifybackup |