On Thu, Mar 16, 2023 at 10:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> PG Bug reporting form <noreply@postgresql.org> writes:
> > When the following query executed with address sanitizers (and
> > -fsanitize=alignment):
> > CREATE EXTENSION ltree;
> > CREATE TABLE lt (t ltree);
> > INSERT INTO lt SELECT format('%s.%s', i / 10, i % 10)::ltree FROM
> > generate_series(1, 200) i;
> > CREATE INDEX ltidx ON lt USING gist (t gist_ltree_ops(siglen=99));
>
> > An incorrect memory access is detected:
> > ltree_gist.c:66:12: runtime error: member access within misaligned address
> > 0x62500019bfd3 for type 'varattrib_4b', which requires 4 byte alignment
>
> Yeah. So if you ask me, the problem here is that the option for
> user-selectable siglen was added with no thought for the possibility
> that there might be undocumented implementation restrictions on the
> value. The code is assuming that siglen is MAXALIGN'd (or at least
> int-aligned, I did not look too closely), and there was nothing wrong
> with that assumption before.
>
> What I'm inclined to do about this is add a restriction that the siglen
> value be a multiple of MAXALIGN. It doesn't look like the reloption
> mechanism has a way to specify that declaratively, but we could probably
> get close enough by just making LTREE_GET_SIGLEN throw an error if it's
> wrong. That's not ideal because you could probably get through making
> an empty index without hitting the error, but I don't offhand see a
> way to make it better.
Sorry for missing this.
Please, note that there are infrastructure of reltoption validators.
I think this is the most appropriate place to check for alignment of
siglen. That works even for empty indexes. See the attached patch.
------
Regards,
Alexander Korotkov