Re: Changing the state of data checksums in a running cluster
От | Tomas Vondra |
---|---|
Тема | Re: Changing the state of data checksums in a running cluster |
Дата | |
Msg-id | d9ea8a27-ed46-476f-8a6e-600147b13ff2@vondra.me обсуждение исходный текст |
Ответ на | Re: Changing the state of data checksums in a running cluster (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: Changing the state of data checksums in a running cluster
|
Список | pgsql-hackers |
On 8/29/25 16:26, Tomas Vondra wrote: > ... > > I've seen these failures after changing checksums in both directions, > both after enabling and disabling. But I've only ever saw this after > immediate shutdown, never after fast shutdown. (It's interesting the > pg_checksums failed only after fast shutdowns ...). > Of course, right after I send a message, it fails after a fast shutdown, contradicting my observation ... > Could it be that the redo happens to start from an older position, but > using the new checksum version? > ... but it also provided more data supporting this hypothesis. I added logging of pg_current_wal_lsn() before / after changing checksums on the primary, and I see this: 1) LSN before: 14/2B0F26A8 2) enable checksums 3) LSN after: 14/EE335D60 4) standby waits for 14/F4E786E8 (higher, likely thanks to pgbench) 5) standby restarts with -m fast 6) redo starts at 14/230043B0, which is *before* enabling checksums I guess this is the root cause. A bit more detailed log attached. regards -- Tomas Vondra
Вложения
В списке pgsql-hackers по дате отправления: