Follow up:
the error detected on master is:
ERROR: XX002: item order invariant violated for index "2722_1401_trends_uint_pkey" DETAIL: Lower index tid=(63203,46) (points to heap tid=(96487,80)) higher index tid=(63203,47) (points to heap tid=(0,0)) page lsn=1F5B/CB8F8098. LOCATION: bt_target_page_check, verify_nbtree.c:1773 query was: SELECT "public".bt_index_check(index := c.oid, heapallindexed := false ) FROM pg_catalog.pg_class c, pg_catalog.pg_index i WHERE c.oid = 151181595 AND c.oid = i.indexrelid AND c.relpersistence != 't' AND i.indisready AND i.indisvalid AND i.indislivebtree index "zabbix._timescaledb_internal._hyper_9_2722_chunk_trends_uint_clock_idx":
Do I get in right,
this corruption was somehow transferred to replicas first, and then wal was tried to apply over corrupted index?
Why it did not crash the master then?
Hi,
Thank you,
there still are 2 broken indexes in master DB,
one of them exactly matches the said relation 151181595.
still,
is it proper wal apply procedure, to segfault in such a case?
On 20/10/2025 20:18, Peter Geoghegan wrote:
On Mon, Oct 20, 2025 at 1:07 PM badfilez@gmail.com <badfilez@gmail.com> wrote:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000057eff2 in _bt_restore_page (page=0x7f6f48fd1000 "", from=0x7f6fe2eccd80 "", len=<optimized out>) at nbtxlog.c:63
63 itemsz = MAXALIGN(itemsz);
(gdb) bt full
"itemsz = 0" suggests that the index was already corrupt, before the
WAL record is applied.
I suggest that you use contrib/amcheck (or the pg_amcheck frontend
program) to ascertain the extent of any index corruption on this
database.
