Re: Failed transaction statistics to measure the logical replication progress

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Failed transaction statistics to measure the logical replication progress
Дата
Msg-id CAA4eK1L3dPeUNu740mu-5znsvXpx2PkRRZ=w1Msf58o=EWSnnQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Failed transaction statistics to measure the logical replication progress  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Failed transaction statistics to measure the logical replication progress  (Greg Nancarrow <gregn4422@gmail.com>)
RE: 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  (Masahiko Sawada <sawada.mshk@gmail.com>)
RE: Failed transaction statistics to measure the logical replication progress  (Hou, Zhijie/侯 志杰 <houzj.fnst@fujitsu.com>)
Список pgsql-hackers
On Tue, Sep 28, 2021 at 11:35 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Tue, Sep 28, 2021 at 1:54 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > >
> > > Then, if, we proceed in this direction,
> > > the place to implement those stats
> > > would be on the LogicalRepWorker struct, instead ?
> > >
> >
> > Or, we can make existing stats persistent and then add these stats on
> > top of it. Sawada-San, do you have any thoughts on this matter?
>
> I think that making existing stats including received_lsn and
> last_msg_receipt_time persistent by using stats collector could cause
> massive reporting messages. We can report these messages with a
> certain interval to reduce the amount of messages but we will end up
> seeing old stats on the view.
>

Can't we keep the current and new stats both in-memory and persist on
disk? So, the persistent stats data will be used to fill the in-memory
counters after restarting of workers, otherwise, we will always refer
to in-memory values.

> Another idea could be to have a separate
> view, say pg_stat_subscription_xact but I'm not sure it's a better
> idea.
>

Yeah, that is another idea but I am afraid that having three different
views for subscription stats will be too much. I think it would be
better if we can display these additional stats via the existing view
pg_stat_subscription or the new view pg_stat_subscription_errors (or
whatever name we want to give it).

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: thomas@habets.se
Дата:
Сообщение: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Gather performance analysis