Re: 024_add_drop_pub.pl might fail due to deadlock
От | Ajin Cherian |
---|---|
Тема | Re: 024_add_drop_pub.pl might fail due to deadlock |
Дата | |
Msg-id | CAFPTHDbyXXbrtYgx=aweMe8YHTXMavJ2FeJmp3iBeEEDjWpbqw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: 024_add_drop_pub.pl might fail due to deadlock ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: 024_add_drop_pub.pl might fail due to deadlock
|
Список | pgsql-hackers |
On Fri, Jul 25, 2025 at 6:01 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > Dear Ajin, > > Thanks for patches! While checking, I recalled that the backpatch policy [1]. > We must not modify definitions of opened functions but this does. Can you define > another function like UpdateSubscriptionRelStateEx or something on the back > branches? > > Another comment: > ``` > @@ -328,9 +328,13 @@ UpdateSubscriptionRelState(Oid subid, Oid relid, char state, > Datum values[Natts_pg_subscription_rel]; > bool replaces[Natts_pg_subscription_rel]; > > - LockSharedObject(SubscriptionRelationId, subid, 0, AccessShareLock); > - > - rel = table_open(SubscriptionRelRelationId, RowExclusiveLock); > + if (already_locked) > + rel = table_open(SubscriptionRelRelationId, NoLock); > ``` > > Can we assert that RowExclusiveLock for pg_subscription_rel has already been > acquired, by using CheckRelationOidLockedByMe() family? > Thanks for your review Kuroda-san, I have changed the logic to not use already_locked and instead check if the locks are taken inside UpdateSubscriptionRelState itself. I've tested this and this works fine. If this logic is acceptable to the reviewers I can update the other patches also in a similar way. regards, Ajin Cherian Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: