Re: Assert in heapgettup_pagemode() fails due to underlying buffer change - Mailing list pgsql-hackers

Hello Thomas,

07.06.2024 09:06, Thomas Munro wrote:
> On Fri, Jun 7, 2024 at 3:06 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> On Fri, Jun 7, 2024 at 3:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>>> My bisect run ended with:
>>> 210622c60e1a9db2e2730140b8106ab57d259d15 is the first bad commit
>>>
>>> Author: Thomas Munro <tmunro@postgresql.org>
>>> Date:   Wed Apr 3 00:03:08 2024 +1300
>>>
>>>       Provide vectored variant of ReadBuffer().
>>>
>>> Other buildfarm failures with this Assert I could find kind of confirm this:
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=calliphoridae&dt=2024-04-03%2003%3A32%3A18
>>> (presumably a first failure of this sort)
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tamandua&dt=2024-04-04%2015%3A38%3A16
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=margay&dt=2024-05-07%2004%3A00%3A08
>> Looking...
> What Noah described[1] is what should be happening already, I think,
> but 210622c6 unconditionally zeroed the page.  Oops.  The attached
> seems to cure his repro for me.  Does it also cure your test?  I
> couldn't see that variant myself for some reason, but it seems to make
> sense as the explanation.  I would probably adjust the function name
> or perhaps consider refactoring slightly, but first let's confirm that
> this is the same issue and fix.

Thank you for looking and for the fix!

Using the same testing procedure (applying patch for checking lpp,
multiplying 026_overwrite_contrecord.pl tests and running 30 tests in
parallel, with fsync=on) which I used for bisecting, I got failures on
iterations 8, 19, 4 without the fix, but with the fix applied, 125
iterations passed. I think The Cure is sound.

Best regards,
Alexander