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
RE: Failed transaction statistics to measure the logical replication progress Re: Failed transaction statistics to measure the logical replication progress RE: Failed transaction statistics to measure the logical replication progress |
Список | 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 по дате отправления: