Re: PG17.6 wal apply bug (SIGSEGV)

Follow up:

the error detected on master is:

ERROR: XX002: item orderinvariant violated forindex"2722_1401_trends_uint_pkey" DETAIL: Lower indextid=(63203,46) (points toheap tid=(96487,80))
higher indextid=(63203,47) (points toheap tid=(0,0)) page lsn=1F5B/CB8F8098. LOCATION: bt_target_page_check, verify_nbtree.c:1773query was:
SELECT"public".bt_index_check(index:= c.oid, heapallindexed := false) FROMpg_catalog.pg_class c, pg_catalog.pg_index i WHEREc.oid = 151181595ANDc.oid
= i.indexrelid ANDc.relpersistence != 't'ANDi.indisready ANDi.indisvalid ANDi.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?

On 22/10/2025 09:19, badfilez(at)gmail(dot)com wrote:
> 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(at)gmail(dot)com <badfilez(at)gmail(dot)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.
>>
>