Re: IPC/MultixactCreation on the Standby server

Dmitry <dsy.075@yandex.ru>

From: Dmitry <dsy.075@yandex.ru>
To: Andrey Borodin <x4mmm@yandex-team.ru>, Álvaro Herrera <alvherre@kurilemu.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-07-29T06:36:00Z
Lists: pgsql-hackers
On 28.07.2025 15:49, Andrey Borodin wrote:
> I also attach a version for PG17, maybe Dmitry could try to reproduce the problem with this patch.

Andrey, thank you very much for your work, and also thanks to Álvaro for 
joining the discussion on the problem. I ran tests on PG17 with patch 
v8, there are no more sessions hanging on the replica, great! Replica 
requests are canceled with recovery conflicts. ERROR: canceling 
statement due to conflict with recovery DETAIL: User was holding shared 
buffer pin for too long. STATEMENT: select sum(val) from tbl2; or ERROR: 
canceling statement due to conflict with recovery DETAIL: User query 
might have needed to see row versions that must be removed. STATEMENT: 
select sum(val) from tbl2;

But on the master, some of the requests then fail with an error, 
apparently invalid multixact's remain in the pages. ERROR: MultiXact 
81926 has invalid next offset STATEMENT: select * from tbl2 where id = 
$1 for no key update; ERROR: MultiXact 81941 has invalid next offset 
CONTEXT: while scanning block 3 offset 244 of relation "public.tbl2" 
automatic vacuum of table "postgres.public.tbl2" Best regards, Dmitry.

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