Re: Assert in heapgettup_pagemode() fails due to underlying buffer change
От | Alexander Lakhin |
---|---|
Тема | Re: Assert in heapgettup_pagemode() fails due to underlying buffer change |
Дата | |
Msg-id | a5cf0a2f-a97f-e350-35bf-d7df5e51e093@gmail.com обсуждение исходный текст |
Ответ на | Re: Assert in heapgettup_pagemode() fails due to underlying buffer change (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Hello Robert, 06.06.2024 19:36, Robert Haas wrote: > On Thu, Jun 6, 2024 at 6:00 AM Alexander Lakhin <exclusion@gmail.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
В списке pgsql-hackers по дате отправления: