Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Ryan Kelly <rpkelly22(at)gmail(dot)com>, tom Tom <tom(at)tomforb(dot)es>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
Date: 2012-05-11 13:52:57
Message-ID: 2941.1336744377@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> I wonder if we should reserve a few of the lwlock "slots" for critical
> sections, to make this less likely to happen. Not only in this case, but
> in general. We haven't seen this problem often, but it would be quite
> trivial to reserve a few slots.

I'm against that: it would complicate a performance-critical and
correctness-critical part of the code, in return for what exactly?
IMO, no part of the system should ever get within an order of magnitude
of holding 100 LWLocks concurrently. For one thing, I don't believe
it's possible to statically guarantee no deadlock once things get that
messy; and for another, it'd surely be horrible from a concurrency
standpoint. So anytime we find something that's reaching that limit,
the solution is to fix the lock usage, not to make the limit more
forgiving.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Simon Riggs 2012-05-11 13:56:25 Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
Previous Message Robert Haas 2012-05-11 13:50:05 Re: BUG #6635: TRUNCATE didn't recreate init fork.