> The fun does not stop there. This also means that the data tracked in
> the file becomes incorrect if a server tries to reuse the same ID
> across two restarts with a different kind attached to them. The point
> is that giving up is kind of always the safest bet and acts as a
> sanity measure, giving priority to the availability of the server.
hmm, that is a different case, right? When we restart with a
different kind ( different struct ) but the same kind ID, we
would find the kind when reading but it may have a different
length, and in that case we will fail reading the entry, and
actually we will have a legitimate corrupt stats file in that
case. Here is what I see in that case.
```
2025-10-20 19:41:14.365 CDT [36636] WARNING: could not read entry of type
2025-10-20 19:41:14.365 CDT [36636] LOG: corrupted statistics file
"pg_stat/pgstat.stat"
```
The more worrying case is if the struct of this other kind has
the same length, and the data ends up being read back
into the wrong fields.
[0] https://github.com/postgres/postgres/blob/master/src/backend/utils/activity/pgstat.c#L1851-L1868
--
Sami
