Re: Resetting spilled txn statistics in pg_stat_replication
От | Amit Kapila |
---|---|
Тема | Re: Resetting spilled txn statistics in pg_stat_replication |
Дата | |
Msg-id | CAA4eK1+E427ZUfzEK8uagMm-F9n33EUBRMC99wMhk81dBRENXA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Resetting spilled txn statistics in pg_stat_replication (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Sep 8, 2020 at 7:53 AM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote: > > On Mon, 7 Sep 2020 at 15:24, Amit Kapila <amit.kapila16@gmail.com> wrote: > > I'm still going to work on this patch although I might be slow > response this month. > This is a quite fast response. Thanks for staying on top of it. > > > > > 9. While reviewing this patch, I noticed that in > > pgstat_read_db_statsfile_timestamp(), if we fail to read ArchiverStats > > or SLRUStats, we return 'false' from this function but OTOH, if we > > fail to read 'D' or 'R' message, we will return 'true'. I feel the > > handling of 'D' and 'R' message is fine because once we read > > GlobalStats, we can return the stats_timestamp. So the other two > > stands corrected. I understand that this is not directly related to > > this patch but if you agree we can do this as a separate patch. > > It seems to make sense to me. We can set *ts and then read both > ArchiverStats and SLRUStats so we can return a valid timestamp even if > we fail to read. > I have started a separate thread for this bug-fix [1] and will continue reviewing this patch. [1] - https://www.postgresql.org/message-id/CAA4eK1J3oTJKyVq6v7K4d3jD%2BvtnruG9fHRib6UuWWsrwAR6Aw%40mail.gmail.com -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: