From: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, 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: | 2022-12-08 13:34:40 |
Message-ID: | 3fcc9f87-1ee7-dff1-bafd-8da94a394390@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/2/19 7:06 PM, Magnus Hagander wrote:
> On Tue, Apr 2, 2019 at 8:47 AM Michael Paquier <michael(at)paquier(dot)xyz <mailto:michael(at)paquier(dot)xyz>> wrote:
>
> On Tue, Apr 02, 2019 at 07:43:12AM +0200, Julien Rouhaud wrote:
> > On Tue, Apr 2, 2019 at 6:56 AM Michael Paquier <michael(at)paquier(dot)xyz <mailto:michael(at)paquier(dot)xyz>> wrote:
> >> One thing which is not
> >> proposed on this patch, and I am fine with it as a first draft, is
> >> that we don't have any information about the broken block number and
> >> the file involved. My gut tells me that we'd want a separate view,
> >> like pg_stat_checksums_details with one tuple per (dboid, rel, fork,
> >> blck) to be complete. But that's just for future work.
> >
> > That could indeed be nice.
>
> Actually, backpedaling on this one... pg_stat_checksums_details may
> be a bad idea as we could finish with one row per broken block. If
> a corruption is spreading quickly, pgstat would not be able to sustain
> that amount of objects. Having pg_stat_checksums would allow us to
> plugin more data easily based on the last failure state:
> - last relid of failure
> - last fork type of failure
> - last block number of failure.
> Not saying to do that now, but having that in pg_stat_database does
> not seem very natural to me. And on top of that we would have an
> extra row full of NULLs for shared objects in pg_stat_database if we
> adopt the unique view approach... I find that rather ugly.
>
>
> I think that tracking each and every block is of course a non-starter, as you've noticed.
I think that's less of a concern now that the stats collector process has gone and that the stats are now collected in shared memory, what do you think?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Reid Thompson | 2022-12-08 14:09:29 | Re: Add tracking of backend memory allocated to pg_stat_activity |
Previous Message | Ashutosh Bapat | 2022-12-08 13:15:52 | Re: Creating HeapTuple from char and date values |