From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Victor Yegorov <vyegorov@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade
Date: Thu, 17 Feb 2022 13:26:30 +0100
Message-ID: <c0c903ee-d53f-9e78-7e3b-1fee2e69922f@enterprisedb.com> (raw)
In-Reply-To: <CAH2-WzkTvnAfAMLfo5Rs+xn0Jnhf4riRt0Q6gu=_H1NO1XJJxQ@mail.gmail.com>
References: <17406-71e02820ae79bb40@postgresql.org>
<cb3a777a-99c7-f671-532d-b828a2223502@enterprisedb.com>
<CAGnEbojzf-uObyWeu1MPNKaYsnL_U2kg48K6Ec43waPRBu3DrQ@mail.gmail.com>
<788a0a51-b1e3-3601-5783-3f6488796ec4@enterprisedb.com>
<CAH2-WzkTvnAfAMLfo5Rs+xn0Jnhf4riRt0Q6gu=_H1NO1XJJxQ@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tomas.vondra@enterprisedb.com, pg@bowt.ie, vyegorov@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade
In-Reply-To: <c0c903ee-d53f-9e78-7e3b-1fee2e69922f@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox