Re: IPC/MultixactCreation on the Standby server

On 27/11/2025 20:25, Andrey Borodin wrote:
>> On 27 Nov 2025, at 01:59, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>
>> This is because the WAL, created with old version, contains records like this:
>>
>> lsn: 0/05561030, prev 0/05561008, desc: CREATE_ID 2047 offset 4093 nmembers 2: 2830 (keysh) 2831 (keysh)
>> lsn: 0/055611A8, prev 0/05561180, desc: ZERO_OFF_PAGE 1
>> lsn: 0/055611D0, prev 0/055611A8, desc: CREATE_ID 2048 offset 4095 nmembers 2: 2831 (keysh) 2832 (keysh)
>
> That's an interesting case. I don't see how SLRU interface can be
> used to test if SLRU page is initialized correctly. We need a
> version of SimpleLruReadPage() that can avoid failure if page does
> not exist yet, and this must not be more expensive than current
> SimpleLruReadPage(). Alternatively we need new
> XLOG_MULTIXACT_CREATE_ID_2 in back branches.

There is SimpleLruDoesPhysicalPageExist() to check if a page has been
initialized. There's also the 'latest_page_number' field which tracks
what is the latest page that has been initialized.

Here's a new version that uses 'latest_page_number' to detect if we're
in this situation (= replaying WAL generated with older minor version).

(I still haven't looked at the tests)

> BTW, my concern about MultiXactState->nextMXact was wrong, now I see
> it. I was almost certain that something is wrong and works by
> accident during summer, but now everything looks 100% correct...

Ok, thanks for double-checking.

> Also, when working on v10 I've asked LLM for help with commit
> message, and it hallucinated Álvaro's e-mail
> <alvherre(at)postgresql(dot)org> IDK, maybe it's real, but it was not used
> in this thread.

Heh, ok, fixed that. You also came up with a last name for Dmitry that I
haven't seen that mentioned anywhere in this thread, either.

>> - I reverted the changes to ExtendMultiXactOffset(), so that it
>> deals with wraparound and FirstMultiXactId the same way as before.
>> The caller never passes FirstMultiXactId, but the changed comments
>> and the assertion were confusing, so I felt it's best to just
>> leave it alone
>
> Maybe move a decision (to extend or not to extend) out of this
> function? Now its purpose is "MaybeExtendMultiXactOffset". And
> there's just one caller.

Perhaps. Let's leave that for a separate non-backported patch though.

- Heikki