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
Ответ на
Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring (Andrey Borodin)
Список
Дерево обсуждения
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 Tom Lane <tgl@sss.pgh.pa.us>
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 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 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>
Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring Tom Lane <tgl@sss.pgh.pa.us>
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
Дата: