Re: Crash in gist insertion on pathological box data

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Crash in gist insertion on pathological box data
Дата
Msg-id 87vdpmzv2q.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Crash in gist insertion on pathological box data  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: Crash in gist insertion on pathological box data  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>>>>> "Teodor" == Teodor Sigaev <teodor@sigaev.ru> writes:
>> even further.  And what confidence do you have that this change>> eliminates all forms of the problem, anyway?
Teodor> Yes, I think. Because that part of code ( if (IS_BADRATIO)Teodor> {...} ) is a corner case itself. In example
fromAndrew, allTeodor> boxes are placed to one page because of floating-pointTeodor> rounding.
 

Yes, it's a corner case, but it arose in real-world data (the test
data set is contrived, but that's simply because it was the easiest
way to demonstrate the bug without access to the real data, which
had a much larger variation in box sizes).
Teodor> We could check IS_BADRATIO again and if it's just put oneTeodor> half of all boxes on one page and another half
tothe anotherTeodor> page as it does if all boxes are equal. But FPeq() seemed toTeodor> me a simpler solution and FP*
comparisonsare widely used inTeodor> geometry.
 

I think that not only does there need to be another IS_BADRATIO check,
but also there needs to be some sort of backstop in gistSplit or
gistUserPicksplit to either recover or (as a last resort) error out
cleanly rather than crash the entire db in cases that would result in
infinite recursion.

-- 
Andrew (irc:RhodiumToad)


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Unsupported effective_io_concurrency platforms
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [GENERAL] string_to_array with empty input