Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring
Дата
Msg-id
595534.1604296428@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring PG Bug reporting form <noreply@postgresql.org>
Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring Andrey Borodin <x4mmm@yandex-team.ru>
Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring Andrey Borodin <x4mmm@yandex-team.ru>
Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring Tom Vijlbrief <tvijlbrief@gmail.com>
Andrey Borodin  writes:
>> 2 нояб. 2020 г., в 10:16, Tom Lane  написал(а):
>> Yeah, I was wondering about that.  Not quite sure it's worth adding
>> cycles to defend against though.

> I think so too. That's why I was not protecting from corruption at all when proposing c60e520.
> Here we can have core dump too if *(srcend+1) produce SegFault:

Right.  The "sp > srcend" check that I added doesn't help if we
were unlucky enough to be right up against the end of memory.
I judged it was cheap enough to be worth including, but I'd
agree that's a judgment call.  Conversely, checking for "off"
being too far back would require tracking the distance back to
the start of the output buffer, which is a value the loop does
not keep ATM.  So that would require adding more cycles to track
(in addition to the actual comparison), which is why it seemed
not quite worth it.

			regards, tom lane


В списке pgsql-bugs по дате отправления
От: Andrey Borodin
Дата:
От: Justin Pryzby
Дата:
FAQ