| 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 |