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: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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 18:32:48
Message-ID: 9944.1336761168@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> OK, I agree.

I still think this is about solving a non-problem.

> The implementation I would prefer would be to put the check in
> START_CRIT_SECTION(); so we actually fail before we enter the section.

... and this is proposing adding significant overhead to solve a
non-problem.

The suggested warning can be added without any new cycles in the normal
case, ie, where we currently have

if (lockcount >= 100)
elog(ERROR, ...);

we can do something like

if (lockcount >= 20)
{
if (lockcount >= 100)
elog(ERROR, ...);
else
elog(WARNING, ...);
}

I think that's more than sufficient. We've had the LWLock mechanism
for umpteen years now, and this hasn't come up before, and now that
it has come up it was because of a locking usage that needed to be
rewritten anyway. That is *not* good evidence for adding complexity
and cycles to the mechanism to make it more failsoft. It shouldn't
need to be failsoft.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Adrian Klaver 2012-05-11 19:39:18 Re: [SQL] pg_dump: aborting because of server version mismatch
Previous Message Simon Riggs 2012-05-11 17:15:53 Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"