Re: Higher level questions around shared memory stats - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Higher level questions around shared memory stats
Date
Msg-id 20220330204424.t45qlf6vxyxjvyjx@alap3.anarazel.de
Whole thread Raw
In response to Re: Higher level questions around shared memory stats  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Hi,

On 2022-03-30 21:44:20 +0200, Peter Eisentraut wrote:
> On 29.03.22 23:01, Andres Freund wrote:
> > > I think what's actually most important here is the error reporting. We need
> > > to make it clear, at least via log messages, that something bad has
> > > happened.
> > The message currently (on HEAD, but similarly on the path) is:
> >                 ereport(pgStatRunningInCollector ? LOG : WARNING,
> >                         (errmsg("corrupted statistics file \"%s\"",
> >                                 statfile)));
> 
> Corrupted how?

We can't parse it. Which can mean that it's truncated (we notice this because
we expect an 'E' as the last byte), bits flipped in the wrong place (there's
different bytes indicating different types of stats). Corruption within
individual stats aren't detected.

Note that this is very old code / behaviour, not meaningfully affected by
shared memory stats patch.


> How does it know?  Is there a checksum, was the file the wrong length, what
> happened?  I think this could use more detail.

I agree. But it's independent of the shared memory stats patch, so I don't
want to tie improving it to that already huge patch.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Next
From: Alvaro Herrera
Date:
Subject: Re: CLUSTER on partitioned index