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 1uzGu4-001bVH-N5 for pgsql-general@arkaria.postgresql.org; Thu, 18 Sep 2025 15:50:36 +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 1uzGu3-00HadT-19 for pgsql-general@arkaria.postgresql.org; Thu, 18 Sep 2025 15:50:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uzGu2-00HadG-Lh for pgsql-general@lists.postgresql.org; Thu, 18 Sep 2025 15:50:34 +0000 Received: from mail-oo1-xc2d.google.com ([2607:f8b0:4864:20::c2d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uzGty-001X1K-2q for pgsql-general@lists.postgresql.org; Thu, 18 Sep 2025 15:50:34 +0000 Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-62192ee029dso265373eaf.0 for ; Thu, 18 Sep 2025 08:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758210630; x=1758815430; 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=MrAVdVmV1IpPmtGBuYHBCEBYomRcK0CLYPsZXu5zOYk=; b=Hw6XZfPfn/fjoV1mHaTbLqNRZ0rqIopZxRdHTKV6LADV9w+tKn2AwViJyPoSC5JwmC qHX544AAIi3vMSyL/ppDnHYc8HT3YHlxlja8zw654hdWFhvhDX+6nYCojoqBv2WbrvbO PmLvWEm5ZvgpplMa1pPH2JAiZPEIOdzk5H2+v2+gE3eBLc9X/7gqLqq1ut7FiJNK03qN ZbQZmJLMAf7ZUzSGHrIXLFEbzE/TsZWsiqOCCylm8OSh1g1NE3wgM/ujyqIZYLqGtufI c5utRNcMc1AE5UFytPhkz7ece7RUZ7Z5ULHL0OTcDxHkaibHH32OjPoodC5sfof4hffM 3t4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758210630; x=1758815430; 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=MrAVdVmV1IpPmtGBuYHBCEBYomRcK0CLYPsZXu5zOYk=; b=NmFYLsTcjjxTSYPrhpNaXEDmp3MXx0SbGmWJ84R5dN6ZrmXlf/ALjISDihG2ij+FUG Hzbmrs/BSSYb2m8NMrB/ZppPuBQ1dk6Nk4pL3okJkxXSQMe/rvlxXwnK49K/8cZSlnpI TLeLru/rIc0r8ur9Z9rOYtNqTLvgLYrEZJHSBGSN71fAM07s/9NSglvoXwogFkEb5zbd tWNOXmEU3SRZGGdCC/z1atYxxIPW3XnTXXNVWtxQbu5qvMp6gFhr5GQaTuy5upyhg/d9 XoDXyacyeaixKtMZjSNzZT/l7FrVSUi/ROetnTmhtpKfnadagzpHCZDhiRH3WtlQLaP3 SAJg== X-Gm-Message-State: AOJu0YwnhsKoZaZ2d2oVu5PuW8TU7Z7Rc7UMiej6aAWbM5RCMa6Jjkas Y5UMwhLUvRB8CwZ4MPWSXDqZRWqRrsBeCHvHXH03i7OuPZsY36qxGW1HriPQAsTtljykCWIqbVA trTAwsz9g8XX2SfnJba2LODL9wn+AtkLl8A== X-Gm-Gg: ASbGncuF0tYT6vqZTOjCtydA+Ylns+tn9j6CIIWJQDGUP1b9/Qfl1Qlls3n5pFUUlCt BlCnlEWEiu+3TfoAt4HaKAqvSZz8X8LDTAL51g6WPD5eETNyEHp2Fp6QHQbaMYscT8ed62BxPcF U/2NlwIzMFP/C6h6IFzu5VdmbyJkEX0/efxbvQVIpfCpwo4kr4ZCGyslFSneGm63++k1fiebig3 aaq6AGJf549/m4VAqAWcW0j/WI= X-Google-Smtp-Source: AGHT+IEmdnhoFmMOcKdIXj6MbZ3x7C15JmnthS6wzUSK/khrGK2puyCdpoRCf2bHCIphKKEUdMlakTG4SWDpoV2oY2E= X-Received: by 2002:a05:6870:1b85:b0:321:2ad1:941a with SMTP id 586e51a60fabf-33bb5067c17mr103337fac.45.1758210629799; Thu, 18 Sep 2025 08:50:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Thu, 18 Sep 2025 11:50:18 -0400 X-Gm-Features: AS18NWBKGIdDsocV2xGz76YZ1nTCrA2qtdW6F4T2HGgYMf0afyZv_J_jYJ96OOg Message-ID: Subject: Re: Index (primary key) corrupt? To: "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="00000000000007958f063f155019" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000007958f063f155019 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 18, 2025 at 10:58=E2=80=AFAM Wim Rouquart = wrote: > Hello, > > > When doing a pg_dump of one of our databases one of the tables primary > keys doesn=E2=80=99t get exported. Pg_dump just skips this index, without= any > warning whatsoever (verbose mode was used to doublecheck). > > > > When doing a REINDEX the issue is fixed. > > > > As this seems to me to be some form of index corruption, I tried using > amcheck (bt_index_check and bt_index_parent_check) to verify for corrupti= on > but both resulted with no issues (the index is a btree). > > > > I would expect the corruption to show up when using amcheck, am I hitting > some kind of bug here? > Does this problem keep happening, or has it only happened once? > Are there any other ways to doublecheck for corruption (without enabling > checksum upfront)? > pg_checksums is available in PG 15. > This concerns a PostgreSQL version 15 btw. > Are you at the current patch level? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --00000000000007958f063f155019 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 18, 2025 at 10:58=E2=80=AFAM = Wim Rouquart <wim.rouquart@kbc.be= > wrote:

Hello,


When doing a pg_dump of one of = our databases one of the tables primary keys doesn=E2=80=99t get exported. = Pg_dump just skips this index, without any warning whatsoever (verbose mode= was used to doublecheck).

=C2=A0

When doing a REINDEX the issue = is fixed.

=C2=A0

As this seems to me to be some = form of index corruption, I tried using amcheck (bt_index_check and bt_inde= x_parent_check) to verify for corruption but both resulted with no issues (= the index is a btree).

=C2=A0

I would expect the corruption t= o show up when using amcheck, am I hitting some kind of bug here?


Does this problem= keep happening, or has it only happened once?
=C2=A0

Are there any other ways to dou= blecheck for corruption (without enabling checksum upfront)?


pg_checksums is available in= PG 15.
=C2=A0=C2=A0

This concerns a PostgreSQL vers= ion 15 btw.

=
Are you at the current patch level?

--
Death to <Redacted>, and butter sau= ce.
Don't boil me, I'm still alive.
<Redacted&g= t; lobster!
--00000000000007958f063f155019--