Re: Assert in heapgettup_pagemode() fails due to underlying buffer change

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assert in heapgettup_pagemode() fails due to underlying buffer change
Date: 2024-06-06 19:00:01
Message-ID: a5cf0a2f-a97f-e350-35bf-d7df5e51e093@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Robert,

06.06.2024 19:36, Robert Haas wrote:
> On Thu, Jun 6, 2024 at 6:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>> Am I missing something or the the page buffer indeed lacks locking there?
> I don't know, but if the locks are really missing now, I feel like the
> first question is "which commit got rid of them?". It's a little hard
> to believe that they've never been there and somehow nobody has
> noticed.
>
> Then again, maybe we have; see Noah's thread about in-place updates
> breaking stuff and some of the surprising discoveries there. But it
> seems worth investigating.

Yes, my last experiment with memcmp for the whole buffer was wrong,
given the comment above heapgettup_pagemode(). I think the correct
check would be:
             ItemId      lpp;
             OffsetNumber lineoff;
+ItemIdData      iid;

             lineoff = scan->rs_vistuples[lineindex];
             lpp = PageGetItemId(page, lineoff);
+iid = *((ItemIdData *)lpp);
+for (int i = 0; i < 1000; i++)
+Assert(memcmp(&iid, lpp, sizeof(iid)) == 0);

It significantly alleviates reproducing of the test failure for me.
Will try to bisect this anomaly tomorrow.

Best regards,
Alexander

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2024-06-06 19:03:41 Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows
Previous Message Jeff Davis 2024-06-06 18:37:08 Re: tiny step toward threading: reduce dependence on setlocale()