| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chris St Denis <chris(at)ctgameinfo(dot)com> |
| Cc: | David Geier <geidav(dot)pg(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: crash in ltree_compare_distance() in 14.24 |
| Date: | 2026-10-30 13:48:19 |
| Message-ID: | 2288826.1793368099@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Chris St Denis <chris(at)ctgameinfo(dot)com> writes:
> 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.
pg_dump is pretty insensitive to corruption in user-table indexes.
It normally reads user tables only via full-table seqscans, which
won't touch the indexes at all. In this case, we can assume that
ltree_compare_distance is being asked to compute the distance between
some ltree value in the index and one in local memory (a value to be
inserted), and it seems it's being passed an incorrect pointer to
the index entry, implying corruption in the index structure.
> 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?
If you don't have a way to reproduce it, then there's not a lot we
can do to investigate. I'd advise just reindexing the troublesome
index and moving on. If you're unsure which is the troublesome
index, reindexing all GIST indexes on ltree columns should be
enough to deal with it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-10-30 16:55:00 | Re: BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed |
| Previous Message | mingjie gao | 2026-10-30 09:50:28 | Re: BUG #19821: pg_restore_attribute_stats() accepts an unsorted scalar histogram_bounds, producing badly wrong row |