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

Andrey Borodin <x4mmm(at)yandex-team(dot)ru> writes:
>> 2 нояб. 2020 г., в 10:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал(а):
>> 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