Re: Higher level questions around shared memory stats

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: Re: Higher level questions around shared memory stats
Date: 2022-03-30 20:44:24
Message-ID: 20220330204424.t45qlf6vxyxjvyjx@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-03-30 20:51:43 Re: CLUSTER on partitioned index
Previous Message Andres Freund 2022-03-30 20:39:27 Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset