Re: Checksum errors in pg_stat_database

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, David Steele <david(at)pgmasters(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Checksum errors in pg_stat_database
Date: 2019-04-04 04:22:40
Message-ID: 20190404042240.GI7693@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2019-04-04 04:25:36 RE: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Previous Message Shawn Debnath 2019-04-04 04:19:45 Re: Refactoring the checkpointer's fsync request queue