Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.
| От | Robert Haas | 
|---|---|
| Тема | Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated. | 
| Дата | |
| Msg-id | CA+TgmoYmHD8CdW+8yh6A=i29Co-2xiiH3YBdBRxKFZ8TqP0V8A@mail.gmail.com обсуждение исходный текст  | 
		
| Ответы | 
                	
            		Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks
 for extensions are allocated.
            		
            		 Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.  | 
		
| Список | pgsql-hackers | 
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: