Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Дата
Msg-id CAA4eK1L-fUijbE86HO9K3a-Jhm8XJ2HK=e6na7M6nD1T3jnSGw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Mon, Mar 16, 2020 at 3:24 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>

+
+ /*
+ * Indicate that the lock is released for certain types of locks
+ */
+#ifdef USE_ASSERT_CHECKING
+ CheckAndSetLockHeld(locallock, false);
+#endif
 }

 /*
@@ -1618,6 +1666,11 @@ GrantLockLocal(LOCALLOCK *locallock, ResourceOwner owner)
  locallock->numLockOwners++;
  if (owner != NULL)
  ResourceOwnerRememberLock(owner, locallock);
+
+ /* Indicate that the lock is acquired for certain types of locks. */
+#ifdef USE_ASSERT_CHECKING
+ CheckAndSetLockHeld(locallock, true);
+#endif
 }

There is no need to sprinkle USE_ASSERT_CHECKING at so many places,
having inside the new function is sufficient.  I have changed that,
added few more comments and
made minor changes.  See, what you think about attached?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Вложения

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

Предыдущее
От: "Ivan N. Taranov"
Дата:
Сообщение: Re: custom postgres launcher for tests
Следующее
От: David Steele
Дата:
Сообщение: Re: plan cache overhead on plpgsql expression