From: | Michael Banck <mbanck(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com>, Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: The ability of postgres to determine loss of files of the main fork |
Date: | 2025-10-01 07:02:09 |
Message-ID: | 68dcd1f2.df0a0220.3300c0.f7af@mx.google.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <aleksander(at)tigerdata(dot)com> 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(at)mbanck-lin-1:~$ psql -c "SELECT COUNT(*) FROM pgbench_accounts"
| count
|----------
| 20000000
|(1 row)
|
|mbanck(at)mbanck-lin-1:~$ rm /tmp/pg_virtualenv.h8ObRG/data/18/regress/base/5/16462.1
|mbanck(at)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(at)mbanck-lin-1:~$ psql -c "SELECT COUNT(*) FROM pgbench_accounts"
| count
|---------
| 7995392
|(1 row)
|
|mbanck(at)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(at)mbanck-lin-1:~$ echo $?
|0
|mbanck(at)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(at)mbanck-lin-1:~$ echo $?
|0
|mbanck(at)mbanck-lin-1:~$
And neither pg_checksums nor pg_basebackup catch it either...
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Zhang Mingli | 2025-10-01 08:15:38 | Fix incorrect function reference BufFileOpenShared in comment. |
Previous Message | Michael Paquier | 2025-10-01 06:49:25 | Re: pgstattuple "unexpected zero page" for gist and hash indexes |