Re: Checksum errors in pg_stat_database

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Checksum errors in pg_stat_database
Дата
Msg-id CABUevEy0ZzFaHa9k3QuzS3VcJS1W+AEEue_jFs1PHZH7DAPhWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Checksum errors in pg_stat_database  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Checksum errors in pg_stat_database  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers


On Thu, Apr 4, 2019 at 6:22 AM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Apr 03, 2019 at 11:56:14AM +0200, Julien Rouhaud wrote:
> 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.

Having pg_stat_database filled with a phantom row full of NULLs to
track checksum failures of shared objects would be confusing I think.
I personally quite like the separate view approach, with one row per
database, but one opinion does not stand as an agreement.

It wouldn't be just that, but it would make sense to include things like blks_read/blks_hit there as well, wouldn't it? As well as read/write time. Things we don't track today, but it could be useful to do so.

But yeah, I'm not strongly in either direction, so if others feel strongly a separate view is better, then we should do a separate view.


Anyway, even if we have no agreement on the shape of what we'd like to
do, I don't think that HEAD is in a proper shape now because we just
don't track a portion of the objects which could have checksum
failures.  So we should either revert the patch currently committed,
or add tracking for shared objects, but definitely not keep the code
in a state in-between.

Definitely. That's why we're discussing it now :) Maybe we should put it on the open items list, because we definitely don't want to ship it one way and then change our mind in the next version.

--

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

Предыдущее
От: "Nagaura, Ryohei"
Дата:
Сообщение: RE: Timeout parameters
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Inheritance, invalidations and prepared statements.