Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Date
Msg-id CAA4eK1L-fUijbE86HO9K3a-Jhm8XJ2HK=e6na7M6nD1T3jnSGw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Dilip Kumar <dilipbalaut@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: "Ivan N. Taranov"
Date:
Subject: Re: custom postgres launcher for tests
Next
From: David Steele
Date:
Subject: Re: plan cache overhead on plpgsql expression