Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.
От | Amit Kapila |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated. |
Дата | |
Msg-id | CAA4eK1LaN1xXRgo2BxQGLYoXeNaQTZOoFOf6Qi19WfZkknZKgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks
for extensions are allocated.
|
Список | pgsql-hackers |
On Mon, Aug 29, 2016 at 10:09 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Aug 27, 2016 at 3:30 AM, Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: