Re: Failed transaction statistics to measure the logical replication progress
От | Amit Kapila |
---|---|
Тема | Re: Failed transaction statistics to measure the logical replication progress |
Дата | |
Msg-id | CAA4eK1K3=jnAHP4UHHLacOAezZTZUcYuNwrKQ21GJENPDYYAaw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Failed transaction statistics to measure the logical replication progress (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Thu, Sep 30, 2021 at 8:18 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Wed, Sep 29, 2021 at 8:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Wed, Sep 29, 2021 at 4:49 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > On Tue, Sep 28, 2021 at 7:04 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > > > 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. > > > > > > Interesting. Probably we can have apply workers and table sync workers > > > send their statistics to the stats collector at exit (before the stats > > > collector shutting down)? And the startup process will restore them at > > > restart? > > > > > > > I think we do need to send at the exit but we should probably send at > > some other regular interval as well to avoid losing all the stats > > after the crash-restart situation. > > But we clear all statistics collected by the stats collector during > crash recovery. > Right. So, maybe if we do what you are suggesting is sufficient. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: