Re: IPC/MultixactCreation on the Standby server - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: IPC/MultixactCreation on the Standby server
Date
Msg-id 5CE827CD-E531-4E5D-8AF4-79A131E684AC@yandex-team.ru
Whole thread Raw
In response to Re: IPC/MultixactCreation on the Standby server  (Kirill Reshke <reshkekirill@gmail.com>)
List pgsql-hackers
Hi Kirill, thanks for looking into this!

> On 20 Aug 2025, at 12:19, Kirill Reshke <reshkekirill@gmail.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
betteremit 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
designfrom 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.


pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pg_dump: fix memory leak
Next
From: Chao Li
Date:
Subject: Re: SQL:2023 JSON simplified accessor support