pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: badfilez@gmail.com <badfilez@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: PG17.6 wal apply bug (SIGSEGV)
Date: Wed, 22 Oct 2025 11:44:38 +0300
Message-ID: <105a1561-9403-4ad4-8754-2520bf5c9bd7@gmail.com> (raw)
In-Reply-To: <630d3d31-40b2-40c2-b1bf-c857ba88322d@gmail.com>
References: <d9d1c712-875f-4cef-aeab-e9346cf6a0a3@gmail.com>
	<bc81dce6-3e38-46ad-92e1-7783560bb9a2@gmail.com>
	<CAH2-WzmMFscVSZ5aU2t22WnD+bSU_g7ayZuGGu8SO2PJPAHahg@mail.gmail.com>
	<630d3d31-40b2-40c2-b1bf-c857ba88322d@gmail.com>

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@gmail.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@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.
>>
>

view thread (5+ messages)  latest in thread

Message-ID: <105a1561-9403-4ad4-8754-2520bf5c9bd7@gmail.com>
Permalink:  ../105a1561-9403-4ad4-8754-2520bf5c9bd7@gmail.com/
Also on:    postgresql.org/message-id/105a1561-9403-4ad4-8754-2520bf5c9bd7@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: badfilez@gmail.com, pg@bowt.ie, pgsql-bugs@lists.postgresql.org
  Subject: Re: PG17.6 wal apply bug (SIGSEGV)
  In-Reply-To: <105a1561-9403-4ad4-8754-2520bf5c9bd7@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox