Re: IPC/MultixactCreation on the Standby server

Andrey Borodin <x4mmm@yandex-team.ru>

From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Dmitry <dsy.075@yandex.ru>, Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-08-29T07:20:40Z
Lists: 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 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.


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix test to work with non-8kB block sizes

  2. Fix setting next multixid's offset at offset wraparound

  3. Add test for multixid wraparound

  4. Set next multixid's offset when creating a new multixid

  5. psql: Improve tab completion for large objects.

  6. Refactor some repetitive SLRU code

  7. Transaction IDs wrap around, per my proposal of 13-Aug-01. More