Re: Checksum errors in pg_stat_database
От | Magnus Hagander |
---|---|
Тема | Re: Checksum errors in pg_stat_database |
Дата | |
Msg-id | CABUevEyXEggREzC=vG09pypc5Z2zkwQ4x=X55xYvk6V1cjdPKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Checksum errors in pg_stat_database (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Checksum errors in pg_stat_database
|
Список | pgsql-hackers |
On Wed, Apr 3, 2019 at 10:44 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
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.
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)
В списке pgsql-hackers по дате отправления: