On Fri, May 17, 2024 at 10:56 AM Jeff Davis wrote:
> 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:
>
>
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
On Thu, May 16, 2024 at 03:54:52PM -0700, Jeff Davis wrote:
> On Mon, 2024-05-13 at 11:15 +1200, Thomas Munro wrote:
>> Perhaps a no-image, no-change registered buffer should not be
>> including an image, even for XLR_CHECK_CONSISTENCY? It's
>> actually
>> useless for consistency
On Mon, 2024-05-13 at 11:15 +1200, Thomas Munro wrote:
> > > > > Perhaps a no-image, no-change registered buffer should not be
> > > > > including an image, even for XLR_CHECK_CONSISTENCY? It's
> > > > > actually
> > > > > useless for consistency checking too I guess, this issue
> > > > > aside,
On Sat, May 11, 2024 at 5:00 PM Alexander Lakhin wrote:
> 11.05.2024 07:25, Thomas Munro wrote:
> > On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin
> > wrote:
> >> 11.05.2024 06:26, Thomas Munro wrote:
> >>> Perhaps a no-image, no-change registered buffer should not be
> >>> including an
11.05.2024 07:25, Thomas Munro wrote:
On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin wrote:
11.05.2024 06:26, Thomas Munro wrote:
Perhaps a no-image, no-change registered buffer should not be
including an image, even for XLR_CHECK_CONSISTENCY? It's actually
useless for consistency checking
On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin wrote:
> 11.05.2024 06:26, Thomas Munro wrote:
> > Perhaps a no-image, no-change registered buffer should not be
> > including an image, even for XLR_CHECK_CONSISTENCY? It's actually
> > useless for consistency checking too I guess, this issue
Hello Thomas and Andres,
Thank you for looking at this!
11.05.2024 06:26, Thomas Munro wrote:
On Sat, May 11, 2024 at 3:57 AM Andres Freund wrote:
On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote:
and discovered that XLogRecordAssemble() calculates CRC over a buffer,
that might be
On Sat, May 11, 2024 at 3:57 AM Andres Freund wrote:
> On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote:
> > and discovered that XLogRecordAssemble() calculates CRC over a buffer,
> > that might be modified by another process.
>
> If, with "might", you mean that it's legitimate for that
Hi,
On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote:
> and discovered that XLogRecordAssemble() calculates CRC over a buffer,
> that might be modified by another process.
If, with "might", you mean that it's legitimate for that buffer to be
modified, I don't think so. The bug is that
Hello hackers,
I've investigated a recent buildfarm failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dodo=2024-05-02%2006%3A40%3A36
where the test failed due to a CRC error:
2024-05-02 17:08:18.401 ACST [3406:7] LOG: incorrect resource manager data
checksum in record at
11 matches
Mail list logo
