From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>,
        Paul A Jungwirth <pj@illuminatedcomputing.com>
cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17300: Server crashes on deserializing text multirange
In-reply-to: <17300-dced2d01ddeb1f2f@postgresql.org>
References: <17300-dced2d01ddeb1f2f@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sat, 27 Nov 2021 18:00:01 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2001127.1638398395.1@sss.pgh.pa.us>
Date: Wed, 01 Dec 2021 17:39:55 -0500
Message-ID: <2001128.1638398395@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2001128.1638398395%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The following query:

> select ('[\"\\\\\",\"\\\\' || repeat('a', 200) ||
> '\"]')::textrange::textmultirange

> leads to the server crash with the following stacktrace:

I think the problem here is that the range bound values inside the
multirange are supposed to be aligned (at least, write_multirange_data
thinks so) but multirange_get_range isn't accounting for the alignment
padding between the two values it extracts.  In this example that
causes it to extract an insane length for the second value.

If so, this would indicate extremely slipshod testing of the multirange
stuff, because the breakage is necessarily reached by multirange_out.

			regards, tom lane