Re: crash in ltree_compare_distance() in 14.24

On 2026-10-28 12:19 p.m., David Geier wrote:
>>> 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.

Data corruption is possible, I recently had an incident with it, however
my thinking was that if this was caused by corruption that the pg_dump
would also crash the server which is not happening. That assumption may
be incorrect.

If corruption is the cause, can you give guidance on what I should do to
repair/validate that data? Which index should be rebuilt/etc? I will be
doing a full dump/restore to upgrade to latest version soonish (need to
validate that new version won't break anything in the application) which
should hopefully remove any issues there.

I do not know gdb very well, so I will need guidance for commands to 'go
down the call stack tosee where "b" gets messed up'. I recompiled
postgres to try to get debugging symbols, and now backtrace is corrupt
so I don't know if I can still get useful data out of the core. I guess
I can go back to the old binary if the data is useful, but as you said
it's an old version.

Unfortunately not using checksums.