Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uXhYt-00DMgg-JC for pgsql-general@arkaria.postgresql.org; Fri, 04 Jul 2025 14:38:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uXhYr-001ALe-Dj for pgsql-general@arkaria.postgresql.org; Fri, 04 Jul 2025 14:38:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uXhYr-001ALR-26 for pgsql-general@lists.postgresql.org; Fri, 04 Jul 2025 14:38:45 +0000 Received: from mail-oo1-xc31.google.com ([2607:f8b0:4864:20::c31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uXhYp-005YU3-2N for pgsql-general@lists.postgresql.org; Fri, 04 Jul 2025 14:38:44 +0000 Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-6116d9bb6ecso683985eaf.3 for ; Fri, 04 Jul 2025 07:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751639923; x=1752244723; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=12+rxl5DKBjDmToXbTyGDpI5K0N+XfnympsydE2Ke2I=; b=NUMLPHx0rg1sNWDa696i0//O9bhEq718o56L1zYOpEAo86KLBnQU+MILjbcbnOCJey BrzX9u1MxfPRcRlIRmdvuxfCn4oiJmJti2r9myoBT71HYnFABLpmp4ybflB4lYv9dhhT quOul+mZr1BtiVHv4eytYpBocgooERlhpTqUwDHTKnMpQOXKati/L+ng9oXMmQt/Q5cg InJ1pNgjw0Kbbzr/6YxTOBzRAJcWpwNR17+SPEwvf4lLXVadHro9FXAfteyYCP/wYuTz QwFfmu7RCZehcbbdfayGFIXtoRqqNwqBg8jDni1yvgSkshq7YJmJlj9n5o5PnpkXlC/S JGQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751639923; x=1752244723; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=12+rxl5DKBjDmToXbTyGDpI5K0N+XfnympsydE2Ke2I=; b=Pkn562ofCvfvl9IVAXbaoMuM4X1wnY6+CEXjyVI5gEa8rVUZQr/U+/fo0OZsiViShU jYke1WU5SEUF3kh0dxMkhHLmjKcbuEvmHpArlpEtMdWTjatdhz572sK3KSy8kUeWWOLb hhtU7ToaUJSr089neoFHZ787J9eMV2VoS0bqDNNwpTrA/IZhAR1XfALlwUO9jrYL2Gs5 H1mV7a0U8PHlrrWPEUnrfeOObcw3KKlrkeUEF287Ajb8vIKX2+fxCJTMCk/16Z5rCwnm Cj0yuhKaX0CETX7MHT+x9p9NAlJJOTE5DtggYwu7ffFQucwoQqW0tr8c9G8llsR9yVwF lydA== X-Gm-Message-State: AOJu0YxhyYavkF8Zge2xFniyo/oU/dPLBptEIpObo67vYFbZPgeIup4g aDOhvmiAnC+5RhHenIJO4z00x+yzfnwEw7cNYYjHwxkJRoGMOQgkGkXhK3gMGCFx52ujzzTYoxn 6uimFtFBPkt/CbN0SWO0Syb9VHPHnXSQ/KQ== X-Gm-Gg: ASbGncvpM/yqk7Qsynt+GbBoOp+G6/XIF4flz5wxqC+7YGdsXf+JI3TemsWblgRrj30 EIO5GlSnWkyXh8BU+bklObCvEMG/5kAV8Po0m/cs4dqotgrTkvyw8g/VpIYsCZDEYFfaGelGGMg rtyP/q5jAHSgsVDIsQuybzBKyOKE8DaJYqvpSd7bKUlgEYHqTs25Z/o+4DCGHWoFAd5WNhsSqlm pz8wQ== X-Google-Smtp-Source: AGHT+IFHy4xvHjh08SAVZPr6X7TJTvsoYt5iSKoss4zyN/x8AoA5mc8fZtuGBf9YbcilXsqIySfYDbRxYxXtqQ1YK4k= X-Received: by 2002:a05:6808:5186:b0:406:2bb4:cd77 with SMTP id 5614622812f47-40d07276771mr1530695b6e.5.1751639922733; Fri, 04 Jul 2025 07:38:42 -0700 (PDT) MIME-Version: 1.0 References: <01df0ca4-cf32-448f-a2cb-e44a8e9f7fd6@element.io> In-Reply-To: <01df0ca4-cf32-448f-a2cb-e44a8e9f7fd6@element.io> From: Ron Johnson Date: Fri, 4 Jul 2025 10:38:31 -0400 X-Gm-Features: Ac12FXxEg6yeJNKPmgQ0bxrZ7HwfFWfMPnKK2gaVyXTx-2FXTKMW7z5fKbKbmtY Message-ID: Subject: Re: Corrupt btree index includes rows that don't match To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000005e7eba06391b7342" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005e7eba06391b7342 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 4, 2025 at 9:49=E2=80=AFAM Erik Johnston wro= te: > Hi, a quick update: > > - We have discovered that the corruption was present from before libicu > update. > - We ran `pg_amcheck --index state_groups_state_type_idx --heapallindexed > matrix`, which returned nothing > - We believe that means that (and matches what we see sampling) the index > has gained extra entries, i.e. that for a given state group it does retur= n > all the relevant rows in the table *plus* extra rows. > > We are also seeing old state groups starting to point at rows that have > only just been inserted. For example, querying for 353864583 on the prima= ry > it returns that row plus four rows that have been inserted today, but on > the backup from last week an index only scan for 353864583 only returns o= ne > row. This makes it feel like the corruption is ongoing? Nothing should ha= ve > modified that state group in the interim (they are generally immutable). > > This naively feels like when inserting a new row we sometimes add the row > to the index twice: once pointing from the correct state group to the new > row, and once from an old state group to the new row? > > Are checksums enabled in the instance? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000005e7eba06391b7342 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 4, 2025 at 9:49=E2=80=AFAM Er= ik Johnston <erikj@element.io>= ; wrote:
=20 =20 =20

Hi, a quick update:

- We have discovered that the corruption was present from before libicu update.
- We ran `pg_amcheck --index state_groups_state_type_idx --heapallindexed matrix`, which returned nothing
- We believe that means that (and matches what we see sampling) the index has gained extra entries, i.e. that for a given state group it does return all the relevant rows in the table plus extra rows.

We are also seeing old state groups starting to point at rows that have only just been inserted. For example, querying for 353864583 on the primary it returns that row plus four rows that have been inserted today, but on the backup from last week an index only scan for 353864583 only returns one row. This makes it feel like the corruption is ongoing? Nothing should have modified that state group in the interim (they are generally immutable).

This naively feels like when inserting a new row we sometimes add the row to the index twice: once pointing from the correct state group to the new row, and once from an old state group to the new row?


Are checksums enabl= ed in=C2=A0the instance?

--
Death to <Redacted>, and butter sauce.
Don't boil me= , I'm still alive.
<Redacted> lobster!
--0000000000005e7eba06391b7342--