Re: IPC/MultixactCreation on the Standby server
Álvaro Herrera <alvherre@kurilemu.de>
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Dmitry <dsy.075@yandex.ru>, pgsql-hackers@lists.postgresql.org
Date: 2025-07-18T11:53:45Z
Lists: pgsql-hackers
Hello, Andrey and I discussed this on IM, and after some back and forth, he came up with a brilliant idea: modify the WAL record for multixact creation, so that the offset of the next multixact is transmitted and can be replayed. (We know it when we create each multixact, because the number of members is known). So the replica can store the offset of the next multixact right away, even though it doesn't know the members for that multixact. On replay of the next multixact we can cross-check that the offset matches what we had written previously. This allows reading the first multixact, without having to wait for the replay of creation of the second multixact. One concern is: if we write the offset for the second mxact, but haven't written its members, what happens if another process looks up the members for that multixact? We'll have to make it wait (retry) somehow. Given what was described upthread, it's possible for the multixact beyond that one to be written already, so we won't have the zero offset that would make us wait. Anyway, he's going to try and implement this. Andrey, please let me know if I misunderstood the idea. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix test to work with non-8kB block sizes
- 7c2061bdfba7 19 (unreleased) landed
-
Fix setting next multixid's offset at offset wraparound
- 48969555447f 14.21 landed
- b9a02b9780bc 15.16 landed
- 4d689a17693e 16.12 landed
- cad40cec24f3 17.8 landed
- 02ba5e3be4f3 18.2 landed
- 4d936c3fff1a 19 (unreleased) landed
-
Add test for multixid wraparound
- 7b81be9b4267 19 (unreleased) landed
-
Set next multixid's offset when creating a new multixid
- 81416e1016dd 14.21 landed
- 8cfb174a61eb 15.16 landed
- 635166913078 16.12 landed
- 8ba61bc06386 17.8 landed
- e46041fd973c 18.2 landed
- 789d65364cde 19 (unreleased) landed
-
psql: Improve tab completion for large objects.
- 14ee8e640300 19 (unreleased) cited
-
Refactor some repetitive SLRU code
- c61678551699 19 (unreleased) cited
-
Transaction IDs wrap around, per my proposal of 13-Aug-01. More
- bc7d37a525c0 7.2.1 cited