Re: Skip unregistered custom kinds on stats load
| От | Sami Imseih |
|---|---|
| Тема | Re: Skip unregistered custom kinds on stats load |
| Дата | |
| Msg-id | CAA5RZ0sszhL0jniiR6e57PKp+DBCGpeN_oDBzfVd6CEoFOH5Dg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Skip unregistered custom kinds on stats load (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Skip unregistered custom kinds on stats load
Re: Skip unregistered custom kinds on stats load |
| Список | 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
В списке pgsql-hackers по дате отправления: