Re: IPC/MultixactCreation on the Standby server
От | Dmitry |
---|---|
Тема | Re: IPC/MultixactCreation on the Standby server |
Дата | |
Msg-id | a31421af-c18a-44f2-92b7-cd2b86eb15dd@yandex.ru обсуждение исходный текст |
Ответ на | Re: IPC/MultixactCreation on the Standby server (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: IPC/MultixactCreation on the Standby server
|
Список | pgsql-hackers |
I'll duplicate the message, the previous one turned out to have poor formatting, sorry. 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.
В списке pgsql-hackers по дате отправления: