| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Manu <manuelreyesbravo(at)gmail(dot)com> |
| Cc: | Daria Lepikhova <daria(dot)n(dot)lepikhova(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Assertion failure in WAL summarizer |
| Date: | 2026-10-24 05:04:47 |
| Message-ID: | CAGRkXqSN7XM6vRYRMUsSrCwiS39MO-dTiED4=KuP5m3Fr7moDg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I think the same root cause can lose data in an incremental backup.
The standby summarizes WAL past the recovery target. If that WAL
truncates a table, the next incremental backup on the promoted server
skips blocks that changed before the target. The restored copy has old
data and no error.
The attached test have a repro.
In my test it goes away if GetLatestLSN() returns the replay position
during recovery. What do you think?
Thanks,
Shihao
| Attachment | Content-Type | Size |
|---|---|---|
| noncfbot-test.txt | text/plain | 4.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-10-24 05:17:49 | Re: [PG19] Promotion hangs behind a backend blocked on a stuck client |
| Previous Message | Zsolt Parragi | 2026-10-24 04:36:50 | Re: [PATCH] Refactor pgbench to make future improvements easier |