From: | Ajin Cherian <itsajin(at)gmail(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 024_add_drop_pub.pl might fail due to deadlock |
Date: | 2025-07-14 09:59:52 |
Message-ID: | CAFPTHDaKcHKtZd1sUF8XmbqS5NUVkYM0FF2mO+fTM_04rWrUjg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 8, 2025 at 8:41 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> Proposed fix:
> In process_syncing_tables_for_apply(), acquire an AccessExclusiveLock
> on SubscriptionRelRelationId before acquiring the lock on
> ReplicationOriginRelationId.
>
> Patch with fix attached.
> I'll continue investigating whether this issue also affects HEAD.
While debugging this further, I found that there is another lock taken
prior to this in AlterSubscription(),
/* Lock the subscription so nobody else can do anything with it. */
LockSharedObject(SubscriptionRelationId, subid, 0, AccessExclusiveLock);
Since this is the first lock taken while altering subscription, that
should also be taken first by the tablesync worker to avoid deadlock.
So, attaching a modified patch.
regards,
Ajin Cherian
Fujitsu Australia
Attachment | Content-Type | Size |
---|---|---|
0002-Fix-a-deadlock-during-ALTER-SUBSCRIPTION-.-DROP-PUBL.patch | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-07-14 10:00:57 | Re: Report bytes and transactions actually sent downtream |
Previous Message | suyu.cmj | 2025-07-14 09:57:18 | Re: The same 2PC data maybe recovered twice |