Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" - Mailing list pgsql-bugs

On 11 May 2012 17:48, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 11.05.2012 18:18, Simon Riggs wrote:
>>
>> On 11 May 2012 15:14, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> =A0wrote:
>>>
>>> On 11.05.2012 16:56, Simon Riggs wrote:
>>>>
>>>>
>>>> On 11 May 2012 11:07, Heikki Linnakangas
>>>> <heikki.linnakangas@enterprisedb.com> =A0 =A0wrote:
>>>>
>>>>> 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.
>>>>
>>>>
>>>>
>>>> Why reserve them solely for critical sections?
>>>
>>>
>>> Because if you run out of lwlocks in a critical section, you get a PANI=
C.
>>
>>
>> Yes, but why reserve them solely for critical sections? If you have an
>> escape hatch you use it, always
>
>
> Well, no, because a PANIC is much worse than an ERROR. Think of this as a
> spare oxygen tank while diving, rather than an escape hatch. A spare tank
> can save your life if you run out of oxygen while ascending, but if you r=
un
> out of oxygen on the way down, you don't continue going down with just the
> spare tank.
>
> Imagine that you have a process that does something like this:
>
> for (i=3D0; i < 99; i++)
> =A0LWLockAcquire(foolock[i])
>
> START_CRIT_SECTION();
>
> XLogInsert(...)
>
> END_CRIT_SECTION();
>
> What happens at the moment is that XLogInsert hits the limit when it tries
> to acquire WALInsertLock, so you get a PANIC. If we reserved, say, 5 locks
> for critical sections, so that you could hold 95 locks while outside a
> critical section, and 5 more within on, you would get an error earlier,
> outside the critical section, while acquiring the "foolocks". Or if the
> number of foolocks acquired was less than 95, you would not get error at
> all. That avoids the PANIC.
>
> You can argue for just raising the limit, but that just moves the problem
> around. It's still possible to hit the limit within a critical section, a=
nd
> PANIC. Likewise, if we lower the limit, that helps us find the problems
> earlier in the development cycle, but doesn't change the fact that if you
> run too close to the edge, you run out of locks within a critical section
> and PANIC.
>
> Of course, nothing stops you from writing (bad) code that acquires a lot =
of
> locks within a critical section, in which case you're screwed anyway.

OK, I agree.

User code can create and hold lwlocks as it chooses, so we need to
protect the server as a whole from bad user code.

The implementation I would prefer would be to put the check in
START_CRIT_SECTION(); so we actually fail before we enter the section.
That way we don't need extra locks, which is good since any additional
amount we pick can still be exceeded by user code.

--=20
=A0Simon Riggs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http:/=
/www.2ndQuadrant.com/
=A0PostgreSQL Development, 24x7 Support, Training & Services