On Tue, May 24, 2016 at 1:29 PM, Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: >> Is this intentional, or should we make the later share-lockers if someone >> is in the wait queue? > > I've already observed such behavior, see . I think that now there is no > consensus on how to fix that. For instance, Andres express opinion that > this shouldn't be fixed from LWLock side . > FYI, I'm planning to pickup work on CSN patch  for 10.0. CSN should fix > various scalability issues including high ProcArrayLock contention.
Some amount of non-fairness is ok, but degrading to the point of complete denial of service is not very graceful. I don't think it's realistic to hope that all lwlock contention issues will be fixed any time soon. Some fallback mechanism would be extremely nice until then. It seems to me that we could fix complete starvation with no noticeable effect on common cases. The general idea would be to have a separate flag bit for starving exclusive lockers. When lock is taken in shared mode an exclusive locker puts itself on the wait queue like it does now, and then proceeds to wait on its semaphore. But differently from now, the semaphore wait has a (configurable?) timeout after which the exclusive locker wakes up and sets the new LW_FLAG_STARVING flag. When this flag is set new shared lockers will now consider the lock taken and will queue up to wait. The exclusive locker that marked itself as starving will get a chance to run once the existing shared lockers complete and wake it up. If there are other nearly starved exclusive lockers they are likely to be at the head of the wait queue and will also get a chance to run. If the wait queue is empty or has a shared locker at the head the starvation flag gets reset and all of the queued up shared lockers get their turn. With the proposed scheme non-starved cases will execute pretty much exactly what they do now, except for a slightly different check for shared lock availability. In starvation scenarios the exclusive lockers will get a chance to run once per starvation grace period. That might still not be ideal or "fair", but it is a lot better than the status quo of indefinitely blocking. PS: if/when you are picking up the CSN work, ping me to write up some of the insights and ideas I have had while thinking about this topic. Regards, Ants Aasma -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers