Re: Higher level questions around shared memory stats
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2022-03-30T20:44:24Z
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
Commits
-
pgstat: remove stats_temp_directory.
- 6f0cf87872ab 15.0 landed
-
pgstat: consistent function comment formatting.
- edadf8098f4b 15.0 landed