Horton
Menu

Re: IPC/MultixactCreation on the Standby server

Dmitry <dsy.075@yandex.ru>

View thread
From: Dmitry <dsy.075@yandex.ru>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-06-25T13:44:39Z
Lists: pgsql-hackers 
On 25.06.2025 12:34, Andrey Borodin wrote:
>
>> On 25 Jun 2025, at 11:11, Dmitry <dsy.075@yandex.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.

Hi Andrey!

Thanks so much for your response.

A small comment on /* Corner case 2: ... */
At this point in the code, I tried to set trace points by outputting 
messages through `elog()`,
and I can say that the process does not always stuck in this part of the 
code, it appears from time to time and in an unpredictable way.

Maybe this will help you a little.

To be honest, PostgreSQL performance is much better with this feature, 
it would be a shame if we had to rollback to the behavior in version 16.

I will definitely try to reproduce the problem with your patch.

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