Re: Checksum errors in pg_stat_database

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Checksum errors in pg_stat_database
Дата
Msg-id CAOBaU_bVsG6RdiitbkbPEwJsTr1b1JetyuvVh3m0j-7sg8U9kg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Checksum errors in pg_stat_database  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Checksum errors in pg_stat_database  (Magnus Hagander <magnus@hagander.net>)
Список 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.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Refactoring the checkpointer's fsync request queue