Обсуждение: BUG #17212: pg_amcheck fails on checking temporary relations

The following bug has been logged on the website:

Bug reference:      17212
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 14.0
Operating system:   Ubuntu 20.04
Description:

When pg_amcheck runs against a database containing temporary tables:
echo "
CREATE TEMP TABLE t(i int);
CREATE INDEX t_idx ON t(i);
INSERT INTO t VALUES (1);

SELECT pg_sleep(5);
" | psql &
pg_amcheck --install-missing -a --heapallindexed --parent-check
--rootdescend --progress || echo "FAIL"

it fails with the following errors:
btree index "regression.pg_temp_4.t_idx":0%)
    ERROR:  cannot access temporary tables of other sessions
    DETAIL:  Index "t_idx" is associated with temporary relation.
heap table "regression.pg_temp_4.t":
    ERROR:  cannot access temporary tables of other sessions
779/779 relations (100%), 2806/2806 pages (100%)
FAIL

Although you can add --exclude-relation=*.pg_temp*.*, this behaviour differs
from the behaviour of pg_dump and friends, which skip such relations
silently.

On Sat, Oct 2, 2021 at 4:49 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
> Although you can add --exclude-relation=*.pg_temp*.*, this behaviour differs
> from the behaviour of pg_dump and friends, which skip such relations
> silently.

I agree -- this behavior is a bug.

Can you propose a fix, Mark?

-- 
Peter Geoghegan

> On Oct 2, 2021, at 10:32 AM, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Sat, Oct 2, 2021 at 4:49 AM PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> Although you can add --exclude-relation=*.pg_temp*.*, this behaviour differs
>> from the behaviour of pg_dump and friends, which skip such relations
>> silently.
>
> I agree -- this behavior is a bug.
>
> Can you propose a fix, Mark?

The attached patch includes a test case for this, which shows the problems against the current pg_amcheck.c, and a new
versionof pg_amcheck.c which fixes the bug.  Could you review it? 

Thanks for bringing this to my attention.



—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company