| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: WAL record CRC calculated incorrectly because of underlying buffer modification |
| Date: | 2024-05-17 14:56:23 |
| Message-ID: | a4e1196a77f154ccf8df486a632d998525a1becc.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2024-05-17 at 10:12 +0900, Michael Paquier wrote:
> That's something I've done four weeks ago in the hash replay code
> path, and having the image with XLR_CHECK_CONSISTENCY even if
> REGBUF_NO_CHANGE was necessary because replay was setting up a LSN on
> a REGBUF_NO_CHANGE page it should not have touched.
Then the candidate fix to selectively break XLR_CHECK_CONSISTENCY is
not acceptable.
>
> Yeah, agreed that getting rid of REGBUF_NO_CHANGE would be nice in
> the
> final picture. It still strikes me as a weird concept that WAL
> replay
> for hash indexes logs full pages just to be able to lock them at
> replay based on what's in the records. :/
I'm still not entirely clear on why hash indexes can't just follow the
rules and exclusive lock the buffer and dirty it. Presumably
performance would suffer, but I asked that question previously and
didn't get an answer:
And if that does affect performance, what about following the same
protocol as XLogSaveBufferForHint()?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-05-17 15:05:42 | Re: commitfest.postgresql.org is no longer fit for purpose |
| Previous Message | Robert Haas | 2024-05-17 14:40:29 | Re: commitfest.postgresql.org is no longer fit for purpose |