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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
Дата
Msg-id 9944.1336761168@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-bugs
Simon Riggs <simon@2ndQuadrant.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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: [SQL] pg_dump: aborting because of server version mismatch