public inbox for [email protected]  

help / color / mirror / Atom feed

From: Arseniy Mukhin <[email protected]>
To: Michael Banck <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: Frits Hoogland <[email protected]>
Cc: [email protected]
Subject: Re: The ability of postgres to determine loss of files of the main fork
Date: Wed, 1 Oct 2025 13:08:33 +0300
Message-ID: <CAE7r3MJBX9aBhfpqfjNYOPvY1KssEuXNGoOocuL4ixKK-TK+bw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAJ7c6TMYvYBQpgv8k+4QnajqPcroOzrj7d3snBBTKX4tHQfVYw@mail.gmail.com>
	<[email protected]>
	<[email protected]>

Hi,

On Wed, Oct 1, 2025 at 10:02 AM Michael Banck <[email protected]> wrote:
>
> Hi,
>
> wow, this is one of the most terrifying threads I've ever seen...
>
> On Tue, Sep 30, 2025 at 12:41:29PM -0400, Tom Lane wrote:
> > Aleksander Alekseev <[email protected]> writes:
> > >> Therefore, I would like to request an enhancement: add an option to
> > >> verify_heapam() that causes the primary key index to be scanned and makes
> > >> sure that all line pointers in the index point to existing tuples.
> >
> > > ... IMO there is little value in adding a check for the existence of
> > > the segments for a single table. And the *real* check will not differ
> > > much from something like SELECT * FROM my_table, or from making a
> > > complete backup of the database.
> >
> > As Frits mentioned, neither of those actions will really notice if a
> > table has been truncated via loss of a segment.
>
> Is there a valid case for a missing segment? If not, couldn't this be
> caught somewhere in the storage manager?
>
> > However, I think the requested functionality already exists via
> > contrib/amcheck (see the heapallindexed option).
>
> It doesn't balk for me, am I doing something wrong?
>
> |mbanck@mbanck-lin-1:~$ psql -c "SELECT COUNT(*) FROM pgbench_accounts"
> |  count
> |----------
> | 20000000
> |(1 row)
> |
> |mbanck@mbanck-lin-1:~$ rm /tmp/pg_virtualenv.h8ObRG/data/18/regress/base/5/16462.1
> |mbanck@mbanck-lin-1:~$ ls /tmp/pg_virtualenv.h8ObRG/data/18/regress/base/5/16462* | grep -v 16462_
> |/tmp/pg_virtualenv.h8ObRG/data/18/regress/base/5/16462
> |/tmp/pg_virtualenv.h8ObRG/data/18/regress/base/5/16462.2
> |mbanck@mbanck-lin-1:~$ psql -c "SELECT COUNT(*) FROM pgbench_accounts"
> |  count
> |---------
> | 7995392
> |(1 row)
> |
> |mbanck@mbanck-lin-1:~$ /usr/lib/postgresql/18/bin/pg_amcheck -v --heapallindexed -t pgbench_accounts
> |pg_amcheck: including database "postgres"
> |pg_amcheck: in database "postgres": using amcheck version "1.5" in schema "public"
> |pg_amcheck: checking heap table "postgres.public.pgbench_accounts"
> |pg_amcheck: checking btree index "postgres.public.pgbench_accounts_pkey"
> |mbanck@mbanck-lin-1:~$ echo $?
> |0
> |mbanck@mbanck-lin-1:~$ /usr/lib/postgresql/18/bin/pg_amcheck -v --heapallindexed -i pgbench_accounts_pkey
> |pg_amcheck: including database "postgres"
> |pg_amcheck: in database "postgres": using amcheck version "1.5" in schema "public"
> |pg_amcheck: checking btree index "postgres.public.pgbench_accounts_pkey"
> |mbanck@mbanck-lin-1:~$ echo $?
> |0
> |mbanck@mbanck-lin-1:~$

I tried to repeat it and has the same results with bt_index_check().
IIUC the reason amcheck doesn't show any corruption here is that
allheapindexed check just builds bloom filter for all index tuples and
then test every heap tuple against it. So we actually never check that
every index tuple points to the existing segment/page/heap_tuple here.


Best regards,
Arseniy Mukhin

view thread (21+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: The ability of postgres to determine loss of files of the main fork
  In-Reply-To: <CAE7r3MJBX9aBhfpqfjNYOPvY1KssEuXNGoOocuL4ixKK-TK+bw@mail.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 agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox