From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | tvijlbrief(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring |
Date: | 2020-11-02 05:02:40 |
Message-ID: | A0C09497-3C7B-44E5-9224-CE86F7E87DBE@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> 2 нояб. 2020 г., в 04:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал(а):
>
>> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>>> This looks to me like a low level issue with Postgres13 and TOAST objects of
>>> a specific size and or compression behavior.
>
> After looking at it some more, I'm pretty sure that these issues could
> explain your problem, though it's possible there's an additional
> contributing issue. If you're in a position to apply a patch and
> see whether it fixes the problem, please try
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=2330f4d3a87ac43b6ecd31bfd698384888ed03cb
Thanks for fixing this, Tom!
1 or 2 extra bytes of match header at the end of sequence of literals is a bug for sure. And the input sequence does not need to be small.
I'm not sure protection from corrupt input is complete within pglz. We still do not protect from matches with offsets before source data. This can SegFault or lead to security leaks. I suspect there may be other go-wild input sequences.
Thanks! Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-11-02 05:16:45 | Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring |
Previous Message | Tom Lane | 2020-11-01 23:45:57 | Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring |