Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Victor Yegorov <vyegorov@gmail.com>,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-02-17T12:26:30Z
Lists: pgsql-bugs
On 2/17/22 03:52, Peter Geoghegan wrote:
> On Wed, Feb 16, 2022 at 4:16 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>> test=# SELECT * FROM gist_page_items(get_raw_page('path_gist_idx', 0),
>> 'path_gist_idx');
>
> Maybe this is obvious, but just in case: gist_page_items is *very*
> trusting here. It's necessary to use gist_page_items_bytea() if you're
> not 100% sure about the index definition for the index page you
> provide. The fact that you can display the contents of each tuple
> using the underlying type's own output function is very handy. But
> potentially hazardous.
>
Sure, but I used this to inspect the index from example in our docs:
https://www.postgresql.org/docs/14/ltree.html#id-1.11.7.30.8
I doubt we can be even more sure about the index definition.
I don't know what the root cause is yet, but the memory corruption
happens simply because ltree_out() sees entirely bogus data when
executed from gist_page_items.
For example it gets 16B varlena, allocates 16B string for it, and starts
iterating over the ltree data. The it finds the first element is 60B
long and happily copies it "into" the 16B buffer. That can't end well,
obviously.
Clearly, the ltree values are mangled somehow / somewhere. The funny
thing is the bytea always looks 8B longer and with bogus data. So for
example if you select this ltree from the table directly
Top.Collections.Pictures.Astronomy.Astronauts
then ltree_out sees it as 80B varlena, with 5 levels. But if ltree_out
gets called from gist_page_items, then it sees 88B with 1 level, which
is completely bogus.
And funnily enough, if you do this at the beginning of ltree_out:
in = (ltree *) ((char *) in + 8);
then gist_page_items() starts working just fine.
So, I guess gist_page_items() is broken/confused in some way. I'm not
sure if this is related to the crash reported by Victor or a separate,
independent issue.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix default signature length for gist_ltree_ops
- bad202c615c9 13.7 landed
- 7d30f59da714 14.3 landed
- 7e74aafc4335 15.0 landed
-
Implement operator class parameters
- 911e70207703 13.0 cited