On Wed, Apr 3, 2019 at 11:31 AM Magnus Hagander <magnus@hagander.net> wrote:
>
> 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.
>
>
> Ugh.
>
> If we wanted per tablespace counters, shouldn't we have a pg_stat_tablespace instead? So we'd have a checksum
failurescounter in pg_state_database separated by database, and one in pg_stat_tablespace separated by tablespace?
(Alongwith 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.
