Thread: pgsql: Code cleanup in the wake of recent LWLock refactoring.

Code cleanup in the wake of recent LWLock refactoring.

As of commit c1772ad9225641c921545b35c84ee478c326b95e, there's no
longer any way of requesting additional LWLocks in the main tranche,
so we don't need NumLWLocks() or LWLockAssign() any more.  Also,
some of the allocation counters that we had previously aren't needed
any more either.

Amit Kapila

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/79a7ff0fe56ac9d782b0734ebb0e7a5299015e58

Modified Files
--------------
src/backend/storage/lmgr/lwlock.c | 89 ++++++++-------------------------------
src/include/storage/lwlock.h      |  2 -
2 files changed, 17 insertions(+), 74 deletions(-)

On 10/02/16 17:12, Robert Haas wrote:
> Code cleanup in the wake of recent LWLock refactoring.
>
> As of commit c1772ad9225641c921545b35c84ee478c326b95e, there's no
> longer any way of requesting additional LWLocks in the main tranche,
> so we don't need NumLWLocks() or LWLockAssign() any more.  Also,
> some of the allocation counters that we had previously aren't needed
> any more either.

(Sorry if this was discussed already, I haven't been paying attention)

LWLockAssign() is used by extensions. Are we OK with just breaking them,
requiring them to change LWLockAssign() with the new mechanism, with
#ifdefs to support multiple server versions? Seems like it shouldn't be
too hard to keep LWLockAssign() around for the benefit of extensions, so
it seems a bit inconsiderate to remove it.

- Heikki