From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Dmitry <dsy(dot)075(at)yandex(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: IPC/MultixactCreation on the Standby server |
Date: | 2025-06-25 09:34:56 |
Message-ID: | D669B1E9-5E87-40DC-9F2E-6B9685D9A81C@yandex-team.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 25 Jun 2025, at 11:11, Dmitry <dsy(dot)075(at)yandex(dot)ru> wrote:
>
> #6 GetMultiXactIdMembers (multi=45559845, members=0x7ffdaedc84b0, from_pgupgrade=<optimized out>, isLockOnly=<optimized out>)
> at /usr/src/postgresql-17-17.5-1.pgdg24.04+1/build/../src/backend/access/transam/multixact.c:1483
Hi Dmitry!
This looks to be related to work in my thread about multixacts [0]. Seems like CV sleep in /* Corner case 2: next multixact is still being filled in */ is not woken up by ConditionVariableBroadcast(&MultiXactState->nextoff_cv) from WAL redo.
If so - any subsequent multixact redo from WAL should unstuck reading last MultiXact.
Either way redo path might be not going through ConditionVariableBroadcast(). I will investigate this further.
Can you please check your reproduction with patch attached to this message? This patch simply adds timeout on CV sleep so in worst case we will fallback to behavior of PG 16.
Best regards, Andrey Borodin.
Attachment | Content-Type | Size |
---|---|---|
0001-Make-next-multixact-sleep-timed.patch | application/octet-stream | 833 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Pyhalov | 2025-06-25 09:37:51 | Re: SCRAM pass-through authentication for postgres_fdw |
Previous Message | Tomas Vondra | 2025-06-25 09:31:36 | Re: pgsql: Introduce pg_shmem_allocations_numa view |