Re: GIN data corruption bug(s) in 9.6devel

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GIN data corruption bug(s) in 9.6devel
Дата
Msg-id 4756.1460072021@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GIN data corruption bug(s) in 9.6devel  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: GIN data corruption bug(s) in 9.6devel  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> To summarize the behavior change:

> In the released code, an inserting backend that violates the pending
> list limit will try to clean the list, even if it is already being
> cleaned.  It won't accomplish anything useful, but will go through the
> motions until eventually it runs into a page the lead cleaner has
> deleted, at which point it realizes there is another cleaner and it
> stops.  This acts as a natural throttle to how fast insertions can
> take place into an over-sized pending list.

Right.

> The proposed change removes that throttle, so that inserters will
> immediately see there is already a cleaner and just go back about
> their business.  Due to that, unthrottled backends could add to the
> pending list faster than the cleaner can clean it, leading to
> unbounded growth in the pending list and could cause a user backend to
> becoming apparently unresponsive to the user, indefinitely.  That is
> scary to backpatch.

It's scary to put into HEAD, either.  What if we simply don't take
that specific behavioral change?  It doesn't seem like this is an
essential part of fixing the bug as you described it.  (Though I've
not read the patch, so maybe I'm just missing the connection.)
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Performance improvement for joins where outer side is unique