Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CAH2-Wzk3NzXYXsUKWBFuBm6aiXTh-_L2Dm9wPqfFenUvG+VbRw@mail.gmail.com>
Date: Wed, 6 Oct 2021 14:45:49 -0700
Cc: Robert Haas <robertmhaas@gmail.com>,
 Pavel Borisov <pashkin.elfe@gmail.com>,
 Alexander Lakhin <exclusion@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <543F3BF3-EDED-4C52-AF05-623921B6C409@enterprisedb.com>
References: <17212-34dd4a1d6bba98bf@postgresql.org>
 <CAH2-Wz=bw-Uk2yoOq7yevC9hyMGgZ2Ud34nd9YJJPXJ3pkVcrw@mail.gmail.com>
 <E85855BD-C063-4B24-9EAA-02DECC8F42B9@enterprisedb.com>
 <E283B45F-5745-49C9-BBC7-99876E2FABD1@enterprisedb.com>
 <f42de8ec-f219-0922-93b3-37a72bba1feb@gmail.com>
 <28B36E41-1E8F-4DC1-A924-711621BA4972@enterprisedb.com>
 <CAH2-Wz=v4py=c79J7wpdVmQMkd8rO7gj5Ur5Dp4E0y7aQUz6cg@mail.gmail.com>
 <386F66EE-DEFD-42EA-9DB2-102BF3414669@enterprisedb.com>
 <CAH2-Wzkwb+1GSONMrXByHhgkzD-N59A_kFcvsoA_+M9cNNHm5g@mail.gmail.com>
 <CA+TgmobJnZE6WMw1y+N9ts36nsbL_un0CYB_khieg8rOa86RBw@mail.gmail.com>
 <CAH2-Wzm02e=jAarpzeZGyK8JyXTvuHCfJ9KC5svosD72nROKrw@mail.gmail.com>
 <B2BDB87C-8288-436E-B3DC-8AEB92FEB8F1@enterprisedb.com>
 <CAH2-Wz=WYdmbc1k8Lr2P4eQeYkh1UYvyDigzrvukejcWc2jKOA@mail.gmail.com>
 <c422a1aa-81c0-0762-0971-9a026cf2aa79@gmail.com>
 <CAH2-WzndLb0-GZcshTJGw6u6SQrJ5puyFiFYh-DWR8ue2zQuvA@mail.gmail.com>
 <CALT9ZEGhuXiH54VgyVJ65V+ccGqPqHTduBM4saPWSD2mrD5C6Q@mail.gmail.com>
 <F824CD5F-C82F-451C-AE67-9AD31447424A@enterprisedb.com>
 <CAH2-WznaYWowxxFaGK6Hv=SUQYS2-r7dQZJFWyDT_W6GGtuCjA@mail.gmail.com>
 <63FF68F5-683D-423E-A667-9C00441101A5@enterprisedb.com>
 <CAH2-Wz=8RP6izkLF=P_bFUK-CyTsO09hQ1-ZsC9P4Qiz3CughQ@mail.gmail.com>
 <561CE3DB-5CBC-44BF-9A3E-1D7FAEB123E0@enterprisedb.com>
 <CA+TgmobtAq9sNa0Z4QNx0xiP4NAobuGOnOirTWdJajkTRFvXNw@mail.gmail.com>
 <CAH2-WzmJkVKFSqJd2_uy07jPg-LW0yCHh0fgA8rFkdyk6FZOnQ@mail.gmail.com>
 <CA+TgmoYa5exExaONEnGBWRdi7A3=FKuKzewY8DXTj6+045wiFQ@mail.gmail.com>
 <CAH2-WzkwRUayddmb3uxCadV_y--DHfY+UMmjtOokiAO2xNh5fA@mail.gmail.com>
 <CA+Tgmoat1M4MAqUQM1H+bkWR=wXmi33bB0YRR=xaFk9ADs5Jeg@mail.gmail.com>
 <CAH2-Wzk3NzXYXsUKWBFuBm6aiXTh-_L2Dm9wPqfFenUvG+VbRw@mail.gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Archived-At: 
 <https://www.postgresql.org/message-id/543F3BF3-EDED-4C52-AF05-623921B6C409%40enterprisedb.com>
Precedence: bulk


> On Oct 6, 2021, at 1:49 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>=20
>> The analogy here is: are we trying to verify that the relations are
>> valid? Or are we just trying to verify that they are as valid as we
>> can expect them to be?
>=20
> I think that we do the latter (or something much closer to the latter
> than to the former). It's actually a very Karl Popper thing. Absence
> of evidence isn't evidence of absence -- period. We can get into a
> conversation about degrees of confidence, but that doesn't seem like
> it'll ever affect how we go about designing these things.
>=20
> A lot of my disagreements around this stuff (especially with Mark)
> seem to stem from this basic understanding of things, in one way or
> another.

I think the disagreements are about something else.

Talking about pg_amcheck "checking" a database, or "checking" a =
relation, is actually short-hand for saying that pg_amcheck handed off =
the objects to amcheck's functions.  The pg_amcheck client application =
itself isn't checking anything.  This short-hand leads to =
misunderstandings that makes it really hard for me to understand what =
people mean in this thread. Your comments suggest that I (or pg_amcheck) =
take some view on whether the database is corrupt, or whether we've =
proven that it is corrupt, or whether we've proven that it is not =
corrupt.  In truth, all the pg_amcheck frontend client can take a view =
on is whether it was able to issue all the commands to the backend that =
it was asked to issue, and whether any of those commands responded with =
an error.

Talking about pg_amcheck "failing" is also confusing.  I don't =
understand what people mean by this.  The example towards the top of =
this thread from Alexander was about pg_amcheck || echo "fail", but that =
suggests that failure is just a question of whether pg_amcheck exited =
with non-zero exit code.  In other parts of the thead, talking about =
pg_amcheck "failing" seems to be used to mean "pg_amcheck has diagnosed =
corruption".  This all gets muddled together.

Upthread, I decided to just make the changes to pg_amcheck that you =
seemed to want, but now I don't know what you want.  Can you opine on =
each of the following.  I need to know what they should print, and =
whether they should return with a non-zero exit status.  I genuinely =
can't post a patch until I know what these are supposed to do, because I =
need to update the regression tests accordingly:=20


pg_amcheck -d db1 -d db2 -d db3 --table=3Dmytable

In this case, mytable is a regular table on db1, a temporary table on =
db2, and an unlogged table on db3, and db3 is in recovery.


pg_amcheck --all --index=3D"*accounting*" --parent-check =
--table=3D"*human_resources*" --table=3D"*peter*"  =
--relation=3D"*alexander*"

Assume a multitude of databases, some primary, some standby, some =
indexes logged, some unlogged, some temporary.  Some of the human =
resources tables are unlogged, some not, and they're scattered across =
different databases, some in recovery, some not.  There is exactly one =
table per database that matches the pattern /*peter*/, but it's =
circumstances are different from one database to the next, and likewise =
for the pattern /*alexander*/ except that in some databases it matches =
an index and in others it matches a table.


I thought that we were headed toward a decision where (despite my =
discomfort) pg_amcheck would downgrade options as necessary, but now it =
sounds like that's not so.  So what should it do

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company