| From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: basebackup: do not verify checksums on pages written before enabling checksums |
| Date: | 2026-08-15 03:23:40 |
| Message-ID: | an/bvN2B7Rn6UTTr@bdtpg |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Fri, Aug 14, 2026 at 09:57:32PM +0200, Daniel Gustafsson wrote:
> > On 14 Aug 2026, at 21:36, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
Thanks for the report and the patch!
> > I am not 100% happy with the shape of the patch, but I couldn't come
> > up with a better solution even after staring at it for a long time,
> > and I think it is at least correct and good enough. But maybe somebody
> > has a better idea for solving this problem.
>
> Thanks! I wasn't able to come up with a mor elegant solution either when
> staring at it but I'll take another look at it together with the other fixes
> staged.
I had a look and I wonder if the boolean could miss an on->off->on series of
changes. checksums_on_at_start would remain true in that case. Once checksums
are enabled again, we'd resume verification even though the final checkpoint may
still be running.
Maybe tracking a checksum transition generation/LSN would make this easier to
reason about? Or am I missing something preventing this case?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan S. Katz | 2026-08-15 03:36:35 | Re: 2026-08-13 release announcement draft |
| Previous Message | Tender Wang | 2026-08-15 03:19:42 | [BUG] hstore integer overflow when constructing large values |