RE: 024_add_drop_pub.pl might fail due to deadlock

Поиск
Список
Период
Сортировка
От Hayato Kuroda (Fujitsu)
Тема RE: 024_add_drop_pub.pl might fail due to deadlock
Дата
Msg-id OS7PR01MB14968EAAE96D2DA149C6CC142F559A@OS7PR01MB14968.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: 024_add_drop_pub.pl might fail due to deadlock  (Ajin Cherian <itsajin@gmail.com>)
Ответы Re: 024_add_drop_pub.pl might fail due to deadlock
Re: 024_add_drop_pub.pl might fail due to deadlock
Список pgsql-hackers
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?

Also, I'm now bit confusing for which branches are really affected. Can you
create all patches for branches, attach at the same e-mail and add some summary
what you want to fix?
E.g., you provided a patch for HEAD/PG15/PG14, what about PG18, 17, 16 and 13?
If not needed, why?

[1]: https://www.postgresql.org/docs/devel/xfunc-c.html#XFUNC-API-ABI-STABILITY-GUIDANCE

Best regards,
Hayato Kuroda
FUJITSU LIMITED


В списке pgsql-hackers по дате отправления: