Re: Checksum errors in pg_stat_database

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Checksum errors in pg_stat_database
Дата
Msg-id CAOBaU_a+1XYagLD=XoDCWS7ZGnZrQst=Ftwqqp9ojvF99Mf72w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Checksum errors in pg_stat_database  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Checksum errors in pg_stat_database  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: COPY FROM WHEN condition
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Ordered Partitioned Table Scans