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 1oVqsL-0002cc-8j for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Sep 2022 08:57:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oVqsJ-0003eF-W2 for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Sep 2022 08:57:35 +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 1oVqsJ-0003e6-I8 for pgsql-hackers@lists.postgresql.org; Wed, 07 Sep 2022 08:57:35 +0000 Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oVqsH-0006qg-56 for pgsql-hackers@postgresql.org; Wed, 07 Sep 2022 08:57:34 +0000 Received: by mail-io1-xd30.google.com with SMTP id y187so11003501iof.0 for ; Wed, 07 Sep 2022 01:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=2AXTt9s9XKnx9jBr4VuPpXqXMsx0ZHZ1dibnyy+sR9k=; b=SaFRZk7mA0cRV7QNmEDE3HAiEqfaWerBeGKSANOoc581v3lI1FpcQ/jlheHaDhAYbF rCfDMBjSTSqxUsIsYYKoUgdNtZ1OPbG4MvHeLzACVgXnL8QIxhhlU604e8pLYNdrCkOj JE3Xjp6GKLo0jQXGYpRpheSJsgcB+MZh2/PDxrwdgx53T79EBawZ0NYlgiQwj0UUs2/J 09AWDV6TekqmHN3HMJOFcxbHoElOpPlSl5N8mTc+MSnB5KjichYB2XwyhEEYJKVjDQ74 SnsrXG9IjQCNwzUQ78OBx3Z8Vk/UGtnNi27cHbDn5jSRqNZX8FvoYNABP70Kc0miKvSo Kp0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=2AXTt9s9XKnx9jBr4VuPpXqXMsx0ZHZ1dibnyy+sR9k=; b=KTW0icKcNkdZ6rAWmjgRS1w89lVhH5ydboP6xZwTvBD6ABkssrX1oT7fRMCGGVDz3l pN11Ap7ITF4EMFuk3SI7y1qCvEbUQnczlI5u3siiRqDnEmHUOQH3dNIUWMs46iSGcQQn B0Qcvcz5Oxh6yCVlStBNmE81j+RzFlUUB+lYEB81ThbNsd1H1eYW+/vVN9zc5le6d3rf nH72bXFt24sN4NUav3nW1Nx0r5xw1S/ll+7ibg2jopuZBcJ4INBczSmfcUn16ARdk4Cf U4rdBDDkxI8KwfRvB0UrV//S4F9rKbluQnMa6aRdlfp1ZTG1WDwlaCp84nmTlV7LLBo5 ++yQ== X-Gm-Message-State: ACgBeo084fTOIa67pP4u63YyegrzM6Xjf9jx6H/a+N6LZZ9DGOhBEsrT PKSUQwY0PGZeTjV+fencMZg9UQ== X-Google-Smtp-Source: AA6agR6/ypOxxatUTYmWUG4ynaktTMDIs/XgnSuRX36usMHsTK1+8wnAQdfX7CDSSjos0XA35Pe1CQ== X-Received: by 2002:a05:6602:1784:b0:688:1e28:1159 with SMTP id y4-20020a056602178400b006881e281159mr1336858iox.130.1662541051088; Wed, 07 Sep 2022 01:57:31 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id a15-20020a056638018f00b00331598832besm6853613jaq.25.2022.09.07.01.57.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Sep 2022 01:57:30 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 6FFCD800785; Wed, 7 Sep 2022 03:57:29 -0500 (CDT) Date: Wed, 7 Sep 2022 03:57:29 -0500 From: Justin Pryzby To: Michael Paquier Cc: Andrey Borodin , pgsql-hackers@postgresql.org, Thomas Munro , Peter Geoghegan , Andres Freund Subject: Re: Different compression methods for FPI Message-ID: <20220907085729.GW31833@telsasoft.com> References: <20210525044444.GV3676@telsasoft.com> <3252174C-C21D-4711-A038-5230DE465BAE@yandex-team.ru> <20210614012412.GA31772@telsasoft.com> <20220902115511.GY31833@telsasoft.com> <20220905002320.GD31833@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Sep 07, 2022 at 03:29:08PM +0900, Michael Paquier wrote: > At the end, I have not taken the approach to use errdetail() for this > problem as errormsg_buf is designed to include an error string. So, I > have finished by refining the error messages generated in > RestoreBlockImage(), consuming them with an ERRCODE_INTERNAL_ERROR. The cases involving max_block_id, has_image and in_use are still "can't happen" cases, which used to hit elog(), and INTERNAL_ERROR sounds right for them. But that's also what'll happen when attempting to replay WAL using a postgres build which doesn't support the necessary compression method. I ran into this while compiling postgres locally while reporting the recovery_prefetch bug, when I failed to compile --with-zstd. Note that basebackup does: src/backend/backup/basebackup_zstd.c- ereport(ERROR, src/backend/backup/basebackup_zstd.c- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), src/backend/backup/basebackup_zstd.c: errmsg("zstd compression is not supported by this build"))); src/backend/backup/basebackup_zstd.c- return NULL; /* keep compiler quiet */ -- Justin