Simon Riggs <si...@2ndquadrant.com> wrote: > I just don't see the reason to do a global search and replace on > the lwlock name I was going to review further before commenting on that, but since it has now come up -- it seems odd that a source file which uses only LW locks needs to change so much for the FlexLock implementation. I'm not sure source code which uses the next layer up from FlexLock should need to be aware of it quite so much. I assume that this was done to avoid adding a layer to some code where it could cause an unnecessary performance hit, but maybe it would be worth just wrapping with a macro to isolate the levels where that's all it takes. For example, if these two macros were defined, predicate.c wouldn't have needed any modifications, and I suspect that is true of many other files (although possibly needing a few other macros): #define LWLockId FlexLockId #define LWLockHeldByMe(lock) FlexLockHeldByMe(lock) Particularly with the function call it seems like it's a mistake to assume that test will always be the same between LW locks and flex locks. There may be a better way to do it than the above, but I think a worthy goal would be to impose zero source code changes on code which continues to use "traditional" lightweight locks. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers