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_bVsG6RdiitbkbPEwJsTr1b1JetyuvVh3m0j-7sg8U9kg@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 Thu, Apr 4, 2019 at 1:25 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Thu, Apr 4, 2019 at 10:47 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
>>
>> Actually we do track counters for shared relations (see
>> pgstat_report_stat), we just don't expose them in any view.  But it's
>> still possible to get the counters manually:
>>
>> # select pg_stat_get_db_blocks_hit(0);
>>  pg_stat_get_db_blocks_hit
>> ---------------------------
>>                    2710329
>> (1 row)
>
>
> Oh, right, we do actually collect it, we just don't show is. So that's another argument *for* having it in
pg_stat_database.Or at least not for having it in a checksum specific view, because then we should really make a
separateview for this as well.
 

Ok, so let's expose all the shared counters in pg_stat_database and
remove the pg_stat_checksum view.

>> My main concern is that pg_stat_get_db_numbackends(0) report something
>> like the total number of backend (though it seems that there's an
>> extra connection accounted for, I don't know which process it's), so
>> if we expose it in pg_stat_database, sum(numbackends) won't make sense
>> anymore.
>
> We could also just hardcoded it so that one always shows 0?

That's a bit hacky, but that's probably the best compromise.  Attached
v4 with all those changes.

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Protect syscache from bloating with negative cache entries
Next
From: Alvaro Herrera
Date:
Subject: Re: Refactoring the checkpointer's fsync request queue