On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de <and...@anarazel.de> wrote: > On 2015-12-12 21:15:52 -0500, Robert Haas wrote: >> On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de <and...@anarazel.de> >> wrote: >> > Here's two patches doing that. The first is an adaption of your >> > constants patch, using an enum and also converting xlog.c's locks. The >> > second is the separation into distinct tranches. >> >> Personally, I prefer the #define approach to the enum, but I can live >> with doing it this way. > > I think the lack needing to adjust the 'last defined' var is worth it... > >> Other than that, I think these patches look >> good, although if it's OK with you I would like to make a pass over >> the comments and the commit messages which seem to me that they could >> benefit from a bit of editing (but not much substantive change). > > Sounds good to me. You'll then commit that?
Yes. Done! In terms of this project overall, NumLWLocks() now knows about only four categories of stuff: fixed lwlocks, backend locks (proc.c), replication slot locks, and locks needed by extensions. I think it'd probably be fine to move the backend locks into PGPROC directly, and the replication slot locks into ReplicationSlot. I don't know if that will improve performance but it doesn't seem like it should regress anything, though we should probably test that. I'm not sure what to do about extension-requested locks - maybe give those their own tranche somehow? I think we should also look at tranche-ifying the locks counted in NUM_FIXED_LWLOCKS but not NUM_INDIVIDUAL_LWLOCKS. That's basically just the lock manager locks and the predicate lock manager locks. That would get us to a place where every lock in the system has a descriptive name, either via the tranche or because it's an individually named lock, which sounds excellent. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
