From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Dmitry <dsy(dot)075(at)yandex(dot)ru>, 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-17 18:34:05 |
Message-ID: | 6F5AE634-DC0C-4433-89C7-2E2BB37AB865@yandex-team.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 30 Jun 2025, at 15:58, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> page_collect_tuples() holds a lock on the buffer while examining tuples visibility, having InterruptHoldoffCount > 0. Tuple visibility check might need WAL to go on, we have to wait until some next MX be filled in.
> Which might need a buffer lock or have a snapshot conflict with caller of page_collect_tuples().
Thinking more about the problem I see 3 ways to deal with this deadlock:
1. We check for recovery conflict even in presence of InterruptHoldoffCount. That's what patch v4 does.
2. Teach page_collect_tuples() to do HeapTupleSatisfiesVisibility() without holding buffer lock.
3. Why do we even HOLD_INTERRUPTS() when aquire shared lock??
Personally, I see point 2 as very invasive in a code that I'm not too familiar with. Option 1 is clumsy. But option 3 is a giant system-wide change.
Yet, I see 3 as a correct solution. Can't we just abstain from HOLD_INTERRUPTS() if taken LWLock is not exclusive?
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Burd | 2025-07-17 18:35:13 | Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock |
Previous Message | Tom Lane | 2025-07-17 18:30:37 | Re: Covering the comparison between date and timestamp, tz, type |