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:

Reply via email to