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-Wzk=vLs8qapiK155uwmzWn6dcK2=3XRE=988V02mmkxJVg@mail.gmail.com>
Date: Mon, 4 Oct 2021 20:19:02 -0700
Cc: Alexander Lakhin <exclusion@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CACF59A6-865B-4D42-B8E4-39CD64F8CEA4@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>
 <71339EFC-3060-4775-B9C6-D39E02752A2F@enterprisedb.com>
 <CAH2-Wz=eqzOwSnwW5eT1AUUUuAhLcojqL+CQaaKs5T6+YR4Rsw@mail.gmail.com>
 <81019B2A-C0EB-4890-BA3A-DB60590AAF43@enterprisedb.com>
 <CAH2-Wzk=vLs8qapiK155uwmzWn6dcK2=3XRE=988V02mmkxJVg@mail.gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Archived-At: 
 <https://www.postgresql.org/message-id/CACF59A6-865B-4D42-B8E4-39CD64F8CEA4%40enterprisedb.com>
Precedence: bulk


> On Oct 4, 2021, at 6:19 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>=20
> I don't see what the point of this example is.

It doesn't matter.

I am changing pg_amcheck to filter out indexes as you say.  Since the =
btree check should no longer error in these cases, the issue of =
pg_amcheck exit(2) sorts itself out without further code changes.

I am changing verify_heapam to skip unlogged tables during recovery.  In =
testing, checking such a table results in a simple notice:

  NOTICE:  cannot verify unlogged relation "u_tbl" during recovery, =
skipping

While testing, I also created an index on the unlogged table and checked =
that index using bt_index_parent_check, and was surprised that checking =
it using bt_index_parent_check raises an error:

  ERROR:  cannot acquire lock mode ShareLock on database objects while =
recovery is in progress
  HINT:  Only RowExclusiveLock or less can be acquired on database =
objects during recovery.

It doesn't get as far as btree_index_mainfork_expected().  So I am =
changing pg_amcheck to filter out indexes when pg_is_in_recovery() is =
true and relpersistence=3D'u'.  Does that sound right to you?

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