Re: Checksum errors in pg_stat_database - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Checksum errors in pg_stat_database
Date
Msg-id CAOBaU_a+1XYagLD=XoDCWS7ZGnZrQst=Ftwqqp9ojvF99Mf72w@mail.gmail.com
Whole thread Raw
In response to Re: Checksum errors in pg_stat_database  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Checksum errors in pg_stat_database
List pgsql-hackers
On Wed, Apr 3, 2019 at 3:43 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> > I can somewhat agree that splitting it  on a per database level might even
> > at that be overdoing it. What might actually be more interesting from a
> > failure-location perspective would be tablespace, rather than any of the
> > others. Or we could reduce it down to just putting it in pg_stat_bgwriter
> > and only count global values perhaps, if in the end we don't think the
> > split-per-database is reasonable?
>
> A split per database or per tablespace is I think a very good thing.
> This helps in tracking down which partitions have gone crazy, and a
> single global counter does not allow that.

Indeed, a per-tablespace would be much more convenient to track the
problem down at the physical level, but we don't have the required
infrastructure for that yet, and it seems quite late to add it now.
IMHO, a per-database has also some value, as it can help to track down
issues at the application level.

Maybe we could add a new column to the view (for instance "source")
which would always be 'database', and we could later add
per-tablespace counters, keeping the view compatibility.



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: COPY FROM WHEN condition
Next
From: Julien Rouhaud
Date:
Subject: Re: Ordered Partitioned Table Scans