On Wed, Apr 3, 2019 at 11:31 AM Magnus Hagander <mag...@hagander.net> wrote: > > On Wed, Apr 3, 2019 at 10:44 AM Julien Rouhaud <rjuju...@gmail.com> wrote: >> >> On Wed, Apr 3, 2019 at 3:43 AM Michael Paquier <mich...@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. > > > Ugh. > > If we wanted per tablespace counters, shouldn't we have a pg_stat_tablespace > instead? So we'd have a checksum failures counter in pg_state_database > separated by database, and one in pg_stat_tablespace separated by tablespace? > (Along with probably a bunch of other entries for tablespaces)
But there's still the problem of reporting errors on shared relation, so pg_stat_database doesn't really fit for that. If we go with a checksum centric view, it'd be strange to have some of the counters in another view.
