> On Oct 6, 2021, at 1:49 PM, Peter Geoghegan <p...@bowt.ie> wrote:
>
>> 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?
>
> 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.
>
> 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:
pg_amcheck -d db1 -d db2 -d db3 --table=mytable
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="*accounting*" --parent-check
--table="*human_resources*" --table="*peter*" --relation="*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
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
