| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| 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-17 09:03:31 |
| Message-ID: | D5DC72A4-0CA7-49ED-9B8B-530D087F9551@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 17 Aug 2026, at 05:07, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> On Sat, Aug 15, 2026 at 03:30:56PM +0100, Zsolt Parragi wrote:
>> There was really an issue there, I think we can solve that by
>> advancing minrecoverypoint.
>
> Yeah, that works too.
Agreed, and there is prior art for this solution.
> IIUC we advance minRecoveryPoint for every checksum state
> record. I wonder if we could do so only when necessary, means when verification
> change (inprogress-on->on and on->inprogress-off). That said that's a nit as
> advancing it for every transition is simpler and less error prone.
I think we should still to doing it for every transition in 19, and if someone
feels like optimizing it can be revisited for 20.
> If we want to check that minRecoveryPoint >= final on record, could the test use
> datachecksums-enable-checksums-delay to pause before that transition and establish
> the restartpoint there?
I tried that in the attached 0002. The risk I see is that it may become flaky
if we don't set about waiting for the next event in time after waking up this
wait. Might not be a problem but the buildfarm has a tendency to expose a lof
of behavior.
> I think that only prove that no false checksum failure is reported.
> Could one post transition backup reuse the existing corruption mechanism (see
> 010_pg_basebackup.pl) to check that verification resumes?
Good idea, also done in 0002.
> 011_standby_straddle.pl does:
>
> +bgwriter_lru_maxpages = 0
>
> but 010_backup_straddle.pl does not. Should 010_backup_straddle.pl also disable
> bgwriter to preserve dirty pages?
I'm not sure, does it need to?
Another thing I am pondering is to place these tests under PG_TEST_EXTRA.
While 128MB for shared_buffers is pretty moderate, I'm not sure we want to
induce that on a normal BF run. 0002 does some backup cleaning as well as a
pgperltidy and pgindent and some very minor fiddling with test code.
--
Daniel Gustafsson
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-basebackup-do-not-verify-checksums-on-pages-from-.patch | application/octet-stream | 29.1 KB |
| v4-0002-Review-hackery.patch | application/octet-stream | 10.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-08-17 09:07:26 | Re: basebackup: do not verify checksums on pages written before enabling checksums |
| Previous Message | David Rowley | 2026-08-17 09:00:02 | Re: redundant double negation prevents IN-subquery pull-up and causes a slower SubPlan |