Re: Checksum errors in pg_stat_database - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Checksum errors in pg_stat_database
Date
Msg-id CAOBaU_ZZP1Ra6gfa0zt7Ryaf1dsG80QX6cdpdvkvb+ZGZx3XVg@mail.gmail.com
Whole thread Raw
In response to Re: Checksum errors in pg_stat_database  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Checksum errors in pg_stat_database
List pgsql-hackers
On Sat, Mar 9, 2019 at 7:50 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Sat, Mar 9, 2019 at 10:41 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
>>
>> Sorry, I have again new comments after a little bit more thinking.
>> I'm wondering if we can do something about shared objects while we're
>> at it.  They don't belong to any database, so it's a little bit
>> orthogonal to this proposal, but it seems quite important to track
>> error on those too!
>>
>> What about adding a new field in PgStat_GlobalStats for that?  We can
>> use the same lastDir to easily detect such objects and slightly adapt
>> sendFile again, which seems quite straightforward.
>
>
> Ah, didn't spot that one until after I pushed :/ Sorry about that.

No problem, I should have thought about it sooner anyway.

> Hmm. That's an interesting thought. And then add a column to pg_stat_bgwriter, I assume?

Yes, and a new entry for PgStat_Shared_Reset_Target I guess.

 (Which is an ever increasingly bad name for the view, but that's
unrelated to this)

yeah :/

> Question is then what number that should show -- only the checksum counter in non-database-fields, or the total
numberacross the cluster?
 

I'd say only for non-database-fields errors, especially if we can
reset each counters separately.  If necessary, we can add a new view
to give a global overview of checksum errors for DBA convenience.


pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Checksum errors in pg_stat_database
Next
From: Andrew Dunstan
Date:
Subject: Re: Should we increase the default vacuum_cost_limit?