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)

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Reply via email to