PG Bug reporting form <noreply@postgresql.org> writes:
> st_numpoints() fetches the whole TOAST object and works fine but
> st_geometrytype() just requests a slice at the front of the TOAST object.
> This looks to me like a low level issue with Postgres13 and TOAST objects of
> a specific size and or compression behavior.
> Could be related to this Postgresql rel_13 commit:
> https://github.com/postgres/postgres/commit/11a078cf87ffb611d19c7dec6df68b41084ad9c9
Hm. I think that pglz_maximum_compressed_size is off a little bit:
it fails to consider that if N decompressed bytes are wanted, we could
have compressed data containing N-1 literal bytes and then a match tag,
which requires 2 or 3 bytes, so that the calculation possibly
underestimates the amount we need by 1 or 2 bytes.
You'd need quite a bit of bad luck to make that happen, though,
especially if the requested length is not small (and 52 bytes
isn't that small).
I suspect the actual bug is in c60e520f6 (Use memcpy instead of a
byte loop in pglz_decompress), which looks fishy to me, although
I can't quite identify what's wrong with it. I wonder if it's
possible for "off" to be zero? Doesn't seem like it should be
in normal use, but then maybe that's what triggers the infinite
loop (rather than just garbage results) if the other bug causes
us to read garbage data.
I think this code is in general too trusting of the input not to
be corrupt --- it doesn't notice a match tag that extends past
the end of the input, either.
regards, tom lane