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-07 10:15:20 |
Message-ID: | CAFPTHDYAO2q33GGcSTQ9dpaUgfyUBvWP9jYZqhM_=fz3g=dcfA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 6, 2025 at 2:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> --- a/src/backend/replication/logical/origin.c
> +++ b/src/backend/replication/logical/origin.c
> @@ -428,6 +428,7 @@ replorigin_drop_by_name(const char *name, bool missing_ok, bool nowait)
> * the specific origin and then re-check if the origin still exists.
> */
> rel = table_open(ReplicationOriginRelationId, ExclusiveLock);
> +pg_usleep(300000);
>
> Not reproduced on REL_16_STABLE (since f6c5edb8a), nor in v14- (because
> 024_add_drop_pub.pl was added in v15).
>
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=petalura&dt=2025-07-01%2018%3A00%3A58
>
> Best regards,
> Alexander
>
Hi Alexander,
Yes, the problem can be reproduced by the changes you suggested. I
will look into what is happening and how we can fix this.
regards,
Ajin Cherian
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Previous Message | Matthias van de Meent | 2025-07-07 10:12:32 | Re: Limiting overshoot in nbtree's parallel SAOP index scans |