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 1os9TI-0003wu-7M for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Nov 2022 21:15:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1os9TH-0006UD-44 for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Nov 2022 21:15:55 +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 1os9TG-0006U4-PT for pgsql-hackers@lists.postgresql.org; Mon, 07 Nov 2022 21:15:54 +0000 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1os9TE-0000E5-FB for pgsql-hackers@postgresql.org; Mon, 07 Nov 2022 21:15:54 +0000 Received: by mail-pg1-x52c.google.com with SMTP id 6so3438173pgm.6 for ; Mon, 07 Nov 2022 13:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ORp2kdu6XL290mvp/YoaylXYR82U7wSbB2UbAEO6tSE=; b=SuWEGLGHxgo365dyS1zfZFWX6zUFMXCQ0tAPttKYKYeBEYfRldTu1ap9EfWwsJ/t2l ivWyDlQcNfRMUn+Ano+kpFTl/KRPA3DZPFSxN76eAu2kqQR93+OiGQqPixofvM68yX8q K1NYz6U15KX4XmLVuu3rc0KBXu5vRfVu2w5TW71QvxtnRvjXYG8Qq7b8WB4RD4jgDkP5 yGfEcXeAHpAtXpN3+21ascmsaquNsHFd+Fm1/O1y9NEALD55YiIcyaZZQYk5+z85Veny rg3VKxfRLHjCn6mMnvJ65Zx8ohvH8fNr1J93c5iBvGaY/vO0aF1Yil8mVBaZdQhhVKh3 KVIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ORp2kdu6XL290mvp/YoaylXYR82U7wSbB2UbAEO6tSE=; b=5dTT6s64ete0B64ig8heCkjFWsnpLGlrinkKF4BnTjD1MN0Q1BbgULoZFOXrwJMowx RPh3fpWEZa5m6cu3wwkbkSDzgE7jnoOe5zQPuRwAZC7T8ARBm8D33ZTxFk7zKcDKhe7O Q4tYp0Tohmu5fq61h8k9gNVYqRliTm8vVQQ8OvjNyUW4PjsRduxEuhkdpmwvW0AQIOms Ww70ZmX3j4seQPam0fayIqeJDUNqspzm1xN9zgEUseP+5MfH5ISfgvliwJN2yqmIHav4 aLQrKufPwKJeX8qwFWMUXHAGrASmcBmBvoYjbBsG3XLOzfRAg3ncmKuq7rB+8gXfpBRH ZMoQ== X-Gm-Message-State: ACrzQf14UVwSQ7A8zL1MtNXKpvATaapYo6G4cAS+7Zr6WAr/9X8g3ltM OFIlf9jezjwSbFjKuUhouJI= X-Google-Smtp-Source: AMsMyM4rlhgp9CuCul6CSJl4LENjdSa38pdsS7EwSECMRux7o6NpMIEvuTxgDCP72h1ngaOeX8/HLw== X-Received: by 2002:a05:6a00:179c:b0:56c:db33:9980 with SMTP id s28-20020a056a00179c00b0056cdb339980mr52863674pfg.76.1667855750468; Mon, 07 Nov 2022 13:15:50 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id j12-20020a170902da8c00b00186b04776b0sm5442460plx.118.2022.11.07.13.15.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Nov 2022 13:15:49 -0800 (PST) Date: Mon, 7 Nov 2022 13:15:47 -0800 From: Nathan Bossart To: Michael Paquier Cc: Kyotaro Horiguchi , bharath.rupireddyforpostgres@gmail.com, tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, benoit.lobreau@gmail.com, alvherre@alvh.no-ip.org, robertmhaas@gmail.com, bossartn@amazon.com, david@pgmasters.net, masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org, magnus@hagander.net, sfrost@snowman.net Subject: Re: archive modules Message-ID: <20221107211547.GA632101@nathanxps13> References: <20221014185130.GC1678424@nathanxps13> <20221014214256.GA1819154@nathanxps13> <20221017.134639.1811443236787336786.horikyota.ntt@gmail.com> <20221105210858.GB137360@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Nov 07, 2022 at 03:20:31PM +0900, Michael Paquier wrote: > On Sat, Nov 05, 2022 at 02:08:58PM -0700, Nathan Bossart wrote: >> Perhaps we could eventually move the archive_command functionality to a >> contrib module (i.e., "shell_archive") so that users must always set >> archive_library. But until then, I suspect it's better to treat modules >> and commands as two separate interfaces to ease migration from older major >> versions (even though archive_command is now essentially a built-in archive >> module). > > I agree that this is a fine long-term goal, removing all traces of the > archive_command from the backend core code. This is actually an > argument in favor of having no traces of XLogArchiveCommand in > pgarch.c, no? ;p Indeed. > I am not sure how long we should wait before being able to do that, > perhaps a couple of years of least? I'd like to think the sooner the > better (like v17?) but we are usually conservative, and the removal of > the exclusive backup mode took 5~6 years if I recall correctly.. Yeah, I imagine we'd need to mark it as deprecated-and-to-be-removed for several years first. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com