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.
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 |