Re: 024_add_drop_pub.pl might fail due to deadlock

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

In response to

Browse pgsql-hackers by date

  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