Re: IPC/MultixactCreation on the Standby server

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Dmitry <dsy(dot)075(at)yandex(dot)ru>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: IPC/MultixactCreation on the Standby server
Date: 2025-08-29 07:20:40
Message-ID: 5CE827CD-E531-4E5D-8AF4-79A131E684AC@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kirill, thanks for looking into this!

> On 20 Aug 2025, at 12:19, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>
> + /*
> + * We might have filled this offset previosuly.
> + * Cross-check for correctness.
> + */
> + Assert((*offptr == 0) || (*offptr == offset));
>
> Should we exit here with errcode(ERRCODE_DATA_CORRUPTED) if *offptr !=
> 0 and *offptr != offset?

No, we should not exit. We encountered inconsistencies that we are fully prepared to fix. But you are right - we should better emit WARNING with XX001.

> + /* Read and adjust next page */
> + next_slotno = SimpleLruReadPage(MultiXactOffsetCtl, next_pageno, true, next);
> + next_offptr = (MultiXactOffset *)
> MultiXactOffsetCtl->shared->page_buffer[next_slotno];
> + next_offptr[next_entryno] = offset + nmembers;
>
> should we check the value of next_offptr[next_entryno] to be equal to
> zero or offset + nmembers ? Assert or
> errcode(ERRCODE_DATA_CORRUPTED) also.

Yes, we'd better WARN user here.

Thanks for your valuable suggestions. I'm not sending new version of the patch, because I'm waiting input on overall design from Alvaro or any committer willing to fix this. We need to figure out if this radical approach is acceptable to backpatch. I do not see other options, but someone might have more clever ideas.

Best regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-08-29 07:22:04 Re: SQL:2023 JSON simplified accessor support
Previous Message Daniel Gustafsson 2025-08-29 07:13:01 Re: pg_dump: fix memory leak