Re: 024_add_drop_pub.pl might fail due to deadlock

From: Ajin Cherian <itsajin(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 024_add_drop_pub.pl might fail due to deadlock
Date: 2025-07-16 03:08:04
Message-ID: CAFPTHDZPFXy+ti=A2gP+h0MMnE+eTam8gbt8jdeReg3ZK+qYjA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 15, 2025 at 2:24 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> Couple of comments:
> 1) This change is not required:
> #include "utils/snapmgr.h"
> #include "utils/syscache.h"
> #include "utils/usercontext.h"
> +#include "utils/injection_point.h"
>
> 2) This can not only happen in error case but also in normal cases
> where the tablesync worker is slower as shown in the script to
> reproduce, we can update the commit message accordingly:
> In most situations the tablesync worker will drop the corresponding
> origin before it
> finishes executing, but if an error causes the tablesync worker to
> fail just prior to
> dropping the origin, the apply worker will later find the origin and drop it.

Thanks for the test and confirming the fix. Fixed the comments.

regards,
Ajin Cherian
Fujitsu Australia

Attachment Content-Type Size
HEAD-v2-0001-Fix-a-possible-deadlock-during-ALTER-SUBSCRIPTION.patch application/octet-stream 2.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message cca5507 2025-07-16 03:21:10 Re: Logical replication launcher did not automatically restart when got SIGKILL
Previous Message Richard Guo 2025-07-16 02:30:35 Re: Pathify RHS unique-ification for semijoin planning