From: | Dmitry <dsy(dot)075(at)yandex(dot)ru> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: IPC/MultixactCreation on the Standby server |
Date: | 2025-07-29 07:17:42 |
Message-ID: | a31421af-c18a-44f2-92b7-cd2b86eb15dd@yandex.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Lukas Fittl | 2025-07-29 07:21:32 | Re: Broken ./configure checks for __cpuid() and __cpuidex() |
Previous Message | Magnus Hagander | 2025-07-29 06:52:34 | Re: [PING] fallocate() causes btrfs to never compress postgresql files |