Re: Failed transaction statistics to measure the logical replication progress

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "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-09-27 04:42:01
Message-ID: CAA4eK1JEVoTJNMu94vVdUoak-uefo9V=XJ5bQQ+o47uawDFftg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 22, 2021 at 10:10 AM osumi(dot)takamichi(at)fujitsu(dot)com
<osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
>
> Just conducted some cosmetic changes
> and rebased my patch, using v14 patch-set in [1].
>

IIUC, this proposal will allow new xact stats for subscriptions via
pg_stat_subscription. One thing that is not clear to me in this patch
is that why you choose a different way to store these stats than the
existing stats in that view? AFAICS, the other existing stats are
stored in-memory in LogicalRepWorker whereas these new stats are
stored/fetched via stats collector means these will persist. Isn't it
better to be consistent here? I am not sure which is a more
appropriate way to store these stats and I would like to hear your and
other's thoughts on that matter but it appears a bit awkward to me
that some of the stats in the same view are persistent and others are
in-memory.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-09-27 05:22:29 Re: Gather performance analysis
Previous Message vignesh C 2021-09-27 04:32:01 Re: Added schema level support for publication.