| From: | Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru> |
|---|---|
| To: | Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Deadlock detector fails to activate on a hot standby replica |
| Date: | 2026-06-26 09:31:27 |
| Message-ID: | 7b1e8353-3d0a-48a1-bac6-2ac6ca91fbde@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Fujii-san, Xuneng Zhou,
> 1) It looks that this patch is doing some refactoring around
> LockBufferForCleanup. The part being touched seems flaky itself on
> HEAD, should we fix the issue in the buffer side first? [1]
Thank you for mentioning it. It seems, there is a conflict with
the another patch due to the introduction of RegisterPinCountWaiter
function, that can not be resolved automatically. I'm ok to wait for
the conflicting fix to be released. It seems, our patch should be
reconsidered after the conflicting patch release.
> 2) buf_state &= ~BM_PIN_COUNT_WAITER in stable versions seems not
> necessary to me as LockBufferForCleanup will handle the clearing for
> us.
It seems it was my mistake when I resolved conflicts when cherry-picking
the changes from other branches. I removed this line in my recent v 6.1
attached patches. Thank you for catching it.
With best regards,
Vitaly
| Attachment | Content-Type | Size |
|---|---|---|
| v6.1-REL_14_STABLE-0001-Fix-deadlock-detector-activation-.patch | text/x-patch | 8.6 KB |
| v6.1-REL_15_STABLE-0001-Fix-deadlock-detector-activation-.patch | text/x-patch | 8.6 KB |
| v6.1-REL_16_STABLE-0001-Fix-deadlock-detector-activation-.patch | text/x-patch | 8.6 KB |
| v6.1-REL_17_STABLE-0001-Fix-deadlock-detector-activation-.patch | text/x-patch | 8.6 KB |
| v6.1-REL_18_STABLE-0001-Fix-deadlock-detector-activation-.patch | text/x-patch | 8.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | cca5507 | 2026-06-26 09:36:36 | Re: Handle concurrent drop when doing whole database vacuum |
| Previous Message | vignesh C | 2026-06-26 09:25:46 | Re: Proposal: Conflict log history table for Logical Replication |