Re: BUG #17847: Unaligned memory access in ltree_gist

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17847: Unaligned memory access in ltree_gist
Date: 2023-04-18 10:16:00
Message-ID: CAPpHfdvvB1-tGha_CXeN5ojWZ48=C77sSrVkgSLLFCVMfv0s1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Alexander,

Thank you for your feedback.

The revised patch is attached.

On Mon, Mar 20, 2023 at 10:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> 19.03.2023 20:08, Alexander Korotkov wrote:
> > On Thu, Mar 16, 2023 at 10:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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.
>
> Thanks for the fix! It works for me.
>
> Maybe it's worth to reflect this restriction in the documentation too?
> <literal>gist_ltree_ops</literal> GiST opclass approximates a set of
> path labels as a bitmap signature. Its optional integer parameter
> <literal>siglen</literal> determines the
> signature length in bytes. The default signature length is 8 bytes.
> Valid values of signature length are between 1 and 2024 bytes.
>
> How about "The length must be a multiple of <type>int</type> alignment between 4 and 2024."?
> (There is a wording "<type>int</type> alignment (4 bytes on most machines)" in catalogs.sgml.)

I think it's a bit contradictory to say that int alignment is 4 bytes
on most machines, but the minimum value is exactly 4. The revised
patch says just that length is positive up to 2024.

> Also maybe change the error message a little:
> s/siglen value must be integer-alignment/siglen value must be integer-aligned/
> or "int-aligned"? (this spelling can be found in src/)

Thank you, accepted.

> (There is also a detail message, that probably should be corrected too:
> DETAIL: Valid values are between "1" and "2024".
> ->
> DETAIL: Valid values are int-aligned positive integers less than 2024.
> ?)

I can't edit directly the detail message for GUC min/max violation.
But I've corrected the min value to INTALIGN(1). Also, I've added
detail message for alignment validation.

I'm going to push this if no objections.

------
Regards,
Alexander Korotkov

Attachment Content-Type Size
0001-Validate-ltree-siglen-GiST-option-v2.patch application/octet-stream 4.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Borisov 2023-04-18 10:34:39 Re: BUG #17847: Unaligned memory access in ltree_gist
Previous Message Tom Lane 2023-04-17 16:18:37 Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields.