| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
| Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17300: Server crashes on deserializing text multirange |
| Date: | 2021-12-01 22:39:55 |
| Message-ID: | 2001128.1638398395@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-12-02 01:49:22 | Re: pg_upgrade test for binary compatibility of core data types |
| Previous Message | Tom Lane | 2021-12-01 22:14:03 | Re: BUG #17302: gist index prevents insertion of some data |