| 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-26 12:59:33 |
| Message-ID: | 1A375E42-E5D3-40FF-B846-E2A2EAAE211C@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 26 Jun 2025, at 14:33, Dmitry <dsy(dot)075(at)yandex(dot)ru> wrote:
>
> On 25.06.2025 16:44, Dmitry wrote:
>> I will definitely try to reproduce the problem with your patch.
> Hi Andrey!
>
> I checked with the patch, unfortunately the problem is also reproducible.
> Client processes wake up after a second and try to get information about the members of the multixact again, in an endless loop.
> At the same time, the WALs are not played, the 'startup' process also hangs on the 'LWLock/BufferContent'.
My hypothesis is that MultiXactState->nextMXact is not filled often enough from redo pathes. So if you are unlucky enough, corner case 2 reading can deadlock with startup.
I need to verify it further, but if so - I's an ancient bug that just happens to be few orders of magnitude more reproducible on 17 due to performance improvements. Still a hypothetical though.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-06-26 13:01:33 | Re: Simplify VM counters in vacuum code |
| Previous Message | Aleksander Alekseev | 2025-06-26 12:46:15 | Re: PG18 protocol version |