Inconsistency in determining the timestamp of the db statfile.
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Date: 2020-09-08T06:10:18Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-inconsistency-in-determining-the-timestamp-of.patch (application/octet-stream) patch v1-0001
We use the timestamp of the global statfile if we are not able to determine it for a particular database either because the entry for that database doesn't exist or there is an error while reading the specific database entry. This was not taken care of while reading other entries like ArchiverStats or SLRUStats. See pgstat_read_db_statsfile_timestamp. I have observed this while reviewing Sawada-San's patch related to logical replication stats [1]. I think this can only happen if due to some reason the statfile got corrupt or we have some bug in stats writing code, the chances of both are rare and even if that happens we will use stale statistics. The attached patch by Sawada-San will fix this issue. As the chances of this the problem is rare and nobody has reported any issue related to this, so it might be okay not to backpatch this. Thoughts? [1] - https://www.postgresql.org/message-id/CAA4eK1JBqQh9cBKjO-nKOOE%3D7f6ONDCZp0TJZfn4VsQqRZ%2BuYA%40mail.gmail.com -- With Regards, Amit Kapila.
Commits
-
Fix inconsistency in determining the timestamp of the db statfile.
- 03c7f1f37a1f 14.0 landed
-
Split pgstat file in smaller pieces
- 187492b6c2e8 9.3.0 cited