Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYCip-0003Cb-EY for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Oct 2021 19:36:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mYCin-0006O1-Kb for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Oct 2021 19:36:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYCin-0006Nt-Cn for pgsql-hackers@lists.postgresql.org; Wed, 06 Oct 2021 19:36:57 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mYCik-0001O8-QB for pgsql-hackers@postgresql.org; Wed, 06 Oct 2021 19:36:56 +0000 Received: by mail-pj1-x102d.google.com with SMTP id on6so2990238pjb.5 for ; Wed, 06 Oct 2021 12:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5RPAjxW56s2H9Xc33BOvgZMM83WC5qPZ+D1tb5Y2RuU=; b=lghTGh3lxBqjw+15YIl2VZCBLzl9GhHCDmyMl/36TMJFNAWxMOQcuEZIrNlUGcAw2t /bVPayVec2dL2XL4kS8Nrl8nAB9yO/RJdsRdUOjl7GELRLK2le1SyJLrRidO7wVaIzo6 skw7TkKwwI51cDtrqt0wwmtQygRld4TL38i9xRwHJHAFJcOqq/WXWQtAvVv2jFVnhAhe B23EGhWuAWDDcNBhzoXfILNhof4EvmMOSm1xLxBEDndm2T3deVK5LKgoZuOZxWuGT/Dv VL3YRn1mFH1H5Fr8d0ggRcpl8Q6xITanL+vaGLFQSNPfX4EKbLo5tp8fCHIiN6wT6PWx cVbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5RPAjxW56s2H9Xc33BOvgZMM83WC5qPZ+D1tb5Y2RuU=; b=wmBoQBcTpVX5+SkFhdWg9xuAuTnN9hYbtlyBlNta54zguuLtamqvswqf0fxisiiD3r QghMfWzzmWjjke6ckykLUiUlx1cI5l0kGKHITPtUgjMxBjEl725/0y+mynb2EDSJMLnE mkdmV30CD1XkKpLPyKYEdREdN/mN4I6oG9JPu3jddNvJniPBQR8rBdyQSIDQmtElIZB+ qsbAX4ZF6v6W3vrNdHYUfR7gYUvFBl2sxboNY+06JSeRqO5IUXl2hRcl1CYgHmrGNs4a iI5wpiy2niZmdm3A6NUjAJkN81c02hOlz6inm49ZZoiTWZPDFiG6peaLPWFg8RgeRJds JykQ== X-Gm-Message-State: AOAM530yHySMPVDvHHBULBGqrBF/5aaRQ1Q2tRIzHn5d9xmF9zm7z4Xs kjpfmgwDJktKAz43XUHhrGeSyk0j2gFNJFLmW/5gmQ0Bt0hktw9dVOkd4HNyIXYie4HZZHcR+je ajx529LCYyYwzvWlsLmDRX0RttI5bm1Rv6BYZNKULvicgQjtQ6iC3WpdLmIyLGTKstbeq7Rpj6I YbRui0FX/IC88r9cToP4t/dWw18so/eWjIEGz7 X-Google-Smtp-Source: ABdhPJzGyJwZJBGghPV89o9i5I9yMLZHiSPKQeZKDnGtjbKhrcnKB7q9yv+UZjuoeNei+s5elvVF4A== X-Received: by 2002:a17:902:c78a:b0:13e:cac2:4b41 with SMTP id w10-20020a170902c78a00b0013ecac24b41mr12714701pla.17.1633549012220; Wed, 06 Oct 2021 12:36:52 -0700 (PDT) Received: from laptop280-ma-us.hitronhub.home (24-113-193-150.wavecable.com. [24.113.193.150]) by smtp.gmail.com with ESMTPSA id i128sm12117325pfc.47.2021.10.06.12.36.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Oct 2021 12:36:51 -0700 (PDT) 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 In-Reply-To: Date: Wed, 6 Oct 2021 12:36:50 -0700 Cc: Robert Haas , Pavel Borisov , Alexander Lakhin , PostgreSQL-development Content-Transfer-Encoding: quoted-printable Message-Id: References: <17212-34dd4a1d6bba98bf@postgresql.org> <28B36E41-1E8F-4DC1-A924-711621BA4972@enterprisedb.com> <386F66EE-DEFD-42EA-9DB2-102BF3414669@enterprisedb.com> <63FF68F5-683D-423E-A667-9C00441101A5@enterprisedb.com> <561CE3DB-5CBC-44BF-9A3E-1D7FAEB123E0@enterprisedb.com> To: Peter Geoghegan X-Mailer: Apple Mail (2.3608.120.23.2.7) X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Oct 6, 2021, at 12:28 PM, Peter Geoghegan wrote: >=20 > I think that what I've said boils down to this: >=20 > * pg_amcheck shouldn't attempt to verify temp relations, on the > grounds that this is fundamentally not useful, and not something that > could ever be sensibly interpreted as "just doing what the user asked > for". Right. I don't think there has been any disagreement on this. There is = a bug in pg_amcheck with respect to this issue, and we all agree on = that. > * pg_amcheck calls to bt_index_check()/bt_index_parent_check() must > only be made with "i.indisready AND i.indisvalid" indexes, just like > the old query from the docs. (Actually, the same query also filters > out temp relations -- which is why I view this issue as almost > identical to the first.) >=20 > Why would the user ask for something that fundamentally doesn't make > any sense? The user may not know that the system has changed. For example, if I see errors in the logs suggesting corruption in a = relation named "mark" and run pg_amcheck --relation=3Dmark, I expect = that to check the relation. If that relation is a temporary table, I'd = like to know that it's not going to be checked, not just have pg_amcheck = report that everything is ok. As another example, if I change my environment variables to connect to = the standby rather than the primary, and forget that I did so, and then = run pg_amcheck --relation=3Dunlogged_relation, I'd rather get a = complaint that I can't check an unlogged relation on a standby than get = nothing. Sure, what I did doesn't make sense, but why should the = application paper over that mistake? =E2=80=94 Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company