Horton
Menu

Re: IPC/MultixactCreation on the Standby server

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers@lists.postgresql.org, Ivan Bykov <i.bykov@modernsys.ru>, Kirill Reshke <reshkekirill@gmail.com>
Date: 2025-11-28T16:21:16Z
Lists: pgsql-hackers

Attachments

On 27/11/2025 20:25, Andrey Borodin wrote:
>> On 27 Nov 2025, at 01:59, Heikki Linnakangas <hlinnaka@iki.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@postgresql.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

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