Re: IPC/MultixactCreation on the Standby server

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

In response to

Responses

Browse pgsql-hackers by date

  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