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 1mYAZW-0005c2-By for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Oct 2021 17:19:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mYAZV-0004ls-9Y for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Oct 2021 17:19:13 +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 1mYAZU-0004lk-NU for pgsql-hackers@lists.postgresql.org; Wed, 06 Oct 2021 17:19:13 +0000 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mYAZM-00006w-Us for pgsql-hackers@postgresql.org; Wed, 06 Oct 2021 17:19:12 +0000 Received: by mail-pg1-x536.google.com with SMTP id g184so3071678pgc.6 for ; Wed, 06 Oct 2021 10:19:04 -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=tBRW7axnabmJMjZD+6IGzwdqe/Gmh2NXddu5YSwLWCI=; b=hnymjYY+wkPM8shdfg/lqfP7mURkp0VZ7StR3KANGBWXDaENKPtTuAxCqc0F+6M9Mu IswWbF5GDYHMI25dKd5cID4rjR+tXp+wiVffWFBt+mioa8bFdSURwbrgm9aI8rGhe+dK PsvulPPOBrSPL0i3SNUWhOslvCPMMofO3DhGkhhWg4aseX2BuFrPaMbMUCIgdDIF2ot6 FI5+ju6d1iGLfYqYdoTqncQS7hKy6+Y3tGwW9+xsaxeuscJ6JC+QqrrBWePynpMxBxBh NmEU1u8NYjgxUSFcYHIX8+cy8S9MUHDQ46H0FRIkxtVp0s1xaBEjnLPYvdbw6g2SQrJn jc/g== 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=tBRW7axnabmJMjZD+6IGzwdqe/Gmh2NXddu5YSwLWCI=; b=7MOkOqSNXctonHrzN4MVW1uoTdQZWquzAIFD7XYpAKtZzKHV5T3cIsn3GZUdwaX7k0 fTDqASvncEE4/ue9XSq954MPo5UZ1r1zHlypjoRl+2yUP4ckidqn1bLu10jvzW6d7GGC zOIXfgJGOsEIouIFLjzFfdqoKKKXy/C0LuRa623erlI08/Vr4wlZvwnYOn7UE0Efh1lS WubwypDqTAr/be6V7MmbM5hGiRwu2ng2p7zq9pQMV2SzXet/xpT3zXPO/W+fqMxJoVzi sZ5SYDyniF/jgowBZycB7Y52gP++eeSAIO/x1yri5V27/u+ETENDtmmkZjkNzpjPBsyb VBTw== X-Gm-Message-State: AOAM5326c84pvI66vet1C4ofXsLJ3rtQhTRn/+hOfF9cIX3l9Lx+rj5m nIZq9xcxh3F8IFFjBn4tIkb1e83IWcBwbPSVfsCapHw//reuTK0B5yQRLUqXWQmUffqi+ssxsgU 8hDwczr9fB82axKNTgLo4sDqjZloa8BrUIgCZ24p6bbQ2YBE7408/hfA2WaD18zwbDs7Fq+zdwJ qI/UdI5qUwHWI7KgSC1AaB0dUgMeyb6afpWT0U X-Google-Smtp-Source: ABdhPJwzGB996LStCr/HKu25B2YIYc9UgNR6b94oKa9gMaRJhSSTHTRvp6+RHW7O7FLZNJvWjn2pzA== X-Received: by 2002:a63:e446:: with SMTP id i6mr22018398pgk.288.1633540742465; Wed, 06 Oct 2021 10:19:02 -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 h2sm5721547pjk.44.2021.10.06.10.19.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Oct 2021 10:19:02 -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 10:19:01 -0700 Cc: Pavel Borisov , Alexander Lakhin , Robert Haas , PostgreSQL-development Content-Transfer-Encoding: quoted-printable Message-Id: <63FF68F5-683D-423E-A667-9C00441101A5@enterprisedb.com> References: <17212-34dd4a1d6bba98bf@postgresql.org> <28B36E41-1E8F-4DC1-A924-711621BA4972@enterprisedb.com> <386F66EE-DEFD-42EA-9DB2-102BF3414669@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 10:16 AM, Peter Geoghegan wrote: >=20 > A return value of 0 cannot be said to indicate that the database is > not corrupt; Nor can a non-zero value be said to indicate that the database is = corrupt. These invocations will still return a non-zero exit status: pg_amcheck -D no_privs_database pg_amcheck --index=3D"no_such_index" pg_amcheck --table=3D"somebody_elses_temp_table" pg_amcheck --index=3D"somebody_elses_temp_index" but these have been modified to no longer do so: pg_amcheck -D my_database_in_recovery --parent-check pg_amcheck -D my_database_in_recovery --heapallindexed pg_amcheck --all Please compare to: find /private || echo "FAIL" rm /not/my/file || echo "FAIL" I'm not sure how the idea that pg_amcheck should never give back a = failure code unless there is corruption got inserted into this thread, = but I'm not on board with that as an invariant statement. The = differences in the upcoming version are 1) --all no longer means "all relations" but rather "all checkable = relations" 2) checking options should be automatically downgraded under = circumstances where they cannot be applied 3) unlogged relations during replication are by definition not corrupt I think #1 and #3 are unsurprising enough that they need no = documentation update. #2 is slightly surprising (at least to me) so I = updated the docs for it. =E2=80=94 Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company