From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Skip unregistered custom kinds on stats load |
Date: | 2025-10-21 00:54:09 |
Message-ID: | CAA5RZ0sszhL0jniiR6e57PKp+DBCGpeN_oDBzfVd6CEoFOH5Dg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mihail Nikalayeu | 2025-10-21 00:55:00 | Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin |
Previous Message | Fujii Masao | 2025-10-20 23:44:48 | Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls |