Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring
| От | Andrey Borodin |
|---|---|
| Тема | Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring |
| Дата | |
| Msg-id | 727877DF-78F7-4C1E-B1A5-C0A97BF276CE@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
|
| Список | pgsql-bugs |
> 2 нояб. 2020 г., в 10:16, Tom Lane <tgl@sss.pgh.pa.us> написал(а): > > Andrey Borodin <x4mmm@yandex-team.ru> writes: >> I'm not sure protection from corrupt input is complete within pglz. We >> still do not protect from matches with offsets before source data. > > 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: len = (sp[0] & 0x0f) + 3; off = ((sp[0] & 0xf0) << 4) | sp[1]; sp += 2; if (len == 18) len += *sp++; if (sp > srcend || off == 0) break; And proper protection would cost nonzero time for branches. I think we should not protect against this. I hope to see lz4 (or something else) in toast and other places one day :) Best regards, Andrey Borodin.
В списке pgsql-bugs по дате отправления: