From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Borodin <x4mmm@yandex-team.ru>
cc: tvijlbrief@gmail.com, pgsql-bugs@lists.postgresql.org,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>
Subject: Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a
 specific TOAST Postgis linestring
In-reply-to: <727877DF-78F7-4C1E-B1A5-C0A97BF276CE@yandex-team.ru>
References: <16694-f107871e499ec114@postgresql.org>
 <543595.1604267856@sss.pgh.pa.us> <578150.1604274357@sss.pgh.pa.us>
 <A0C09497-3C7B-44E5-9224-CE86F7E87DBE@yandex-team.ru>
 <592336.1604294205@sss.pgh.pa.us>
 <727877DF-78F7-4C1E-B1A5-C0A97BF276CE@yandex-team.ru>
Comments: In-reply-to Andrey Borodin <x4mmm@yandex-team.ru>
	message dated "Mon, 02 Nov 2020 10:33:09 +0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <595533.1604296428.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 02 Nov 2020 00:53:48 -0500
Message-ID: <595534.1604296428@sss.pgh.pa.us>
Precedence: bulk

Andrey Borodin <x4mmm@yandex-team.ru> writes:
>> 2 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3., =D0=B2 10:16, Tom Lane <tgl@s=
ss.pgh.pa.us> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>> 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 w=
hen 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