> 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
