Re: crash in ltree_compare_distance() in 14.24

>> In case you cannot reproduce it, can you share at least the query you
>> were running and the relevant parts of the schema?
>
> It happened in the middle of the night, has not happened since.
>
> The ltree column id_tree contains a ltree of comment ID's showing the
> tree of comment replies.
>
> Logs show this
>
>      2026-10-26 02:26:35.914 PDT [61206] LOG:  server process (PID
>    50023) was terminated by signal 11: Segmentation fault
>      2026-10-26 02:26:35.914 PDT [61206] DETAIL:  Failed process was
>    running: INSERT INTO "story_comments" ("comment", "reply_to",
>    "deleted", "id_tree", "sid", "user_id", "ipaddr") VALUES ($1, $2,
>    $3, $4, $5, $6, $7)
>
> Due to parameterised queries, I do not have the data values that were
> inserted.
>
> Here is the table structure.
Thanks for sharing the details.

What can be concluded from the core dump information you shared in your
first mail is that the read of b->numlevel in

float
ltree_compare_distance(const ltree *a, const ltree *b)
{
ltree_level *al = LTREE_FIRST(a);
ltree_level *bl = LTREE_FIRST(b);
int an = a->numlevel;
int bn = b->numlevel;

causes the segfault, likely because "b" is a corrupted pointer. The
value of b is 0x127a2f2a13, which is unaligned and far away from "a"
which is 0x2fa39243b1d8 and aligned as expected. Beyond that, the "a"
ltree is empty / has 0 levels as can be inferred from edx = 0.

I tried to create a failing test case based on your schema details but
failed. I'm assuming that the order of INSERTs and the data matters.

What you could try is open your core dump and go down the call stack to
see where "b" gets messed up. It would also be interesting which of the
two calls to ltree_compare_distance() in ltree_penalty() causes the
segfault.

Do you use data checksums? If not, maybe the issue stems from a data
corruption on disk?

FYI: PostgreSQL 14 reaches end of life on November 12, 2026. Though, I
think it's not unlikely that this bug is also on master.

--
David Geier