On Fri, Jun 9, 2017 at 2:39 PM, Jim Van Fleet <vanfleet@us.ibm.com> wrote:
> I left out the retry in LWLockAcquire.
If you want this to be considered, you should add it to the next
CommitFest, currently https://commitfest.postgresql.org/14/
However, I can't see this being acceptable in the current form:
1. I'm pretty sure that there will be no appetite for introducing
special cases for ProcArrayLock into lwlock.c directly; such logic
should be handled by the code that calls lwlock.c. It's very
unpalatable to have LWLockConditionalAcquire() harcoded to fail always
for ProcArrayLock, and it's also adding overhead for every caller that
reaches those "if" statements and has to branch or not.
2. Always using the group-clearing approach instead of only when the
lock is uncontended seems like it will lead to a loss of performance
in some situations.
3. This adds a good amount of complexity to the code but it's not
clearly better overall. Your own results in
http://postgr.es/m/OFBAB24999.8DB8C8DE-ON86258136.006AEB24-86258136.006B30C8@notes.na.collabserv.com
show that some workloads benefit and others are harmed. I don't think
a 6% loss on single-socket machines is acceptable; there are still
plenty of those out there.
I don't think the idea of partitioning ProcArrayLock is necessarily
bad -- Heikki tried it before -- but I don't think it's necessarily
easy to work out all the kinks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company