Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
To: Peter Geoghegan <pg@bowt.ie>, Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
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>
From: Alexander Lakhin <exclusion@gmail.com>
Message-ID: <c422a1aa-81c0-0762-0971-9a026cf2aa79@gmail.com>
Date: Wed, 6 Oct 2021 09:00:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
 <CAH2-Wz=WYdmbc1k8Lr2P4eQeYkh1UYvyDigzrvukejcWc2jKOA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
 <https://www.postgresql.org/message-id/c422a1aa-81c0-0762-0971-9a026cf2aa79%40gmail.com>
Precedence: bulk

Hello Mark, Peter, Robert,
05.10.2021 20:22, Peter Geoghegan пишет:
> On Tue, Oct 5, 2021 at 10:03 AM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
>> I took no offense.  Actually, I owe you a thank-you for having put so much effort into debating the behavior with me.  I think the patch to fix bug #17212 will be better for it.
> Glad that you think so. And, thanks for working on the issue so promptly.
>
> This was a question of fundamental definitions. Those are often very tricky.
Thanks for the discussion and fixing the issues! (I haven't found the
latest fix in the thread yet, but I agree with the approach.)

I think that ideally pg_amcheck should not fail on a live database, that
does not contain corrupted data, and should not affect the database
usage by other users (as it's "only a check").
So for example, pg_amcheck should run successfully in parallel with
`make installcheck` and should not cause any of the tests fail. (There
could be nuances with, say, volatile functions called by the index
expressions, but in general it could be possible.)
I tried to run the following script:
(for i in `seq 100`; do echo "=== iteration $i ===" >>pg_amcheck.log;
pg_amcheck -a --install-missing --heapallindexed --rootdescend
--progress >>pg_amcheck.log 2>&1 || echo "FAIL" >>pg_amcheck.log; done) &
make installcheck

And got several deadlocks again (manifested by some tests failing) and
also "ERROR:  could not open relation with OID xxxx" - that could be
considered as a transition state (it is possible without locking), that
cause pg_amcheck to report an overall error.

Best regards,
Alexander