On Mon, Aug 29, 2016 at 10:09 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Aug 27, 2016 at 3:30 AM, Andres Freund <and...@anarazel.de> wrote: >> Hi, >> >> On 2016-02-04 21:43:14 +0000, Robert Haas wrote: >>> Change the way that LWLocks for extensions are allocated. >>> >>> The previous RequestAddinLWLocks() method had several disadvantages. >>> First, the locks would be in the main tranche; we've recently decided >>> that it's useful for LWLocks used for separate purposes to have >>> separate tranche IDs. Second, there wasn't any correlation between >>> what code called RequestAddinLWLocks() and what code called >>> LWLockAssign(); when multiple modules are in use, it could become >>> quite difficult to troubleshoot problems where LWLockAssign() ran out >>> of locks. To fix, create a concept of named LWLock tranches which >>> can be used either by extension or by core code. >>> >>> Amit Kapila and Robert Haas >> >> I noticed that this code has no test coverage: >> >> http://coverage.postgresql.org/src/backend/storage/lmgr/lwlock.c.gcov.html >> >> It'd be good to add some, although I'm not entirely sure what the best >> way is. Maybe add a simple pg_stat_statements test? > > That would also have the advantage of improving the test coverage for > pg_stat_statements, which is at the moment quite a bit thinner than > the coverage for lwlock.c. >
I will write such a test case either in this week or early next week. I hope this is not super urgent, let me know if you think otherwise. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
