| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Greg Burd <greg(at)burd(dot)me> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, andres(at)anarazel(dot)de, pgsql(at)j-davis(dot)com, thomas(dot)munro(at)gmail(dot)com, exclusion(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com, hlinnaka(at)iki(dot)fi |
| Subject: | Re: WAL record CRC calculated incorrectly because of underlying buffer modification |
| Date: | 2026-10-29 02:27:24 |
| Message-ID: | auKvDKa3umaD7Hwi@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 28, 2026 at 01:29:39PM +0000, Greg Burd wrote:
> - CRC reproduction: primary + streaming standby,
> wal_consistency_checking = 'hash', 8 sessions inserting and deleting
> on a single-bucket index, aggressive autovacuum.
>
> A: the standby stopped on "incorrect resource manager data checksum"
> in all runs, as expected (control case).
>
> B, C, D: the standby caught up with no errors, 3 of 3 each.
That sounds encouraging, as a start.
Could you start a new thread about all that, with all the authors of
this original code in CC at least? Hiding such a large refactoring on
a thread for the CRC failure would not help in terms of attracting
the attention this requires in terms of reviews.
You could also add me in CC if you wish. As far as I recall, we
rely on the registered buffer at replay to lift a bit the lock
restrictions for concurrency purposes, but that's pretty specialized
in itself.
Thanks,
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-10-29 02:37:50 | Re: Bogus recovery conflicts due to outdated XLogReceiptTime |
| Previous Message | Michael Paquier | 2026-10-29 02:19:14 | Re: WAL record CRC calculated incorrectly because of underlying buffer modification |