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 1pPuje-00029e-U5 for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 00:24:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pPujd-0008Lq-3w for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 00:24:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pPujc-0008Lg-P3 for pgsql-hackers@lists.postgresql.org; Thu, 09 Feb 2023 00:24:20 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pPuja-0003m8-6b for pgsql-hackers@lists.postgresql.org; Thu, 09 Feb 2023 00:24:19 +0000 Received: by mail-pj1-x102f.google.com with SMTP id d2so547486pjd.5 for ; Wed, 08 Feb 2023 16:24:17 -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=nqHFP/QUsEbFSRTat5l0nGQMUpe3SbPg5qomNSqOCBI=; b=A92HnoORx2BJ4vvQDO3MItCHi41cJINjAtiV1nCWUQ/+H8sfcvCfYnG7ypc5UEq+9c w3LgtQAdcjrUuJ/N+F7SDK2Z/XGBLBbv0BbfYSgPuwQOCQsbUB/QuSxQtg/8BE3xy+qT hWhKKNJ33EEYtPbXgAYCeCFLFcP+WaY8ApTlWVb8Y11LkvrC3DlE5LB30hLFRrWPKuZO /iN5RUzKfCWV0qK16M68b2lMJBDOOBtKWBPz/Z5WVRjb7EoBeczvTF7BsSSwW2BfoUSv m9yjgY1LMBENg+4zePLwM3NtavpIi3JawHVc/CGuCISeSS5vcSqfpoEpB4YX90Dmr4jy FdUg== 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=nqHFP/QUsEbFSRTat5l0nGQMUpe3SbPg5qomNSqOCBI=; b=BwCTJlYJ0iBj6UOJt8NprUOhXHu7LPpke9b5/USPddtHDnWIAOMP3xxKzlk28Uq9m3 nMNtoVzHwSSvR8c1cMvONym7akacDuZrakU8xmLAFqRSROTkB6YeIxOPBuZDQRBk96bW rUXkgQA/7c3Le3vFeUnNcqS4ilb36DEPIwzb6P2AypldUoQnIMaSJQGV/4ogV2Ne6m4N 2cAEPpMdwUvaXIBnT8MoQ6Db8KM2aCvO1ISD7hPxQhcBHVu+uRSCptMjyZITCrRAs6ae T48pWWfDMzkqwUxfr+q5hLG+2hmZuHLkYxH1jiG8doxm5CXYpZburExg4N4fz2Vo0xfJ AjNQ== X-Gm-Message-State: AO0yUKXOYf/WcRt4OnqYykbEs8VS6WGS+2jFeBglmD507FssY/z9zQgh 2yvkfZEAO4xdd7Tvz4uh7jY= X-Google-Smtp-Source: AK7set9XpUoajrO3IMY9fL8UNzErRJfjLf7Fc/ff8JcZUlhapuGpnyowI0qpznFrv0zF3LhnmG1L0Q== X-Received: by 2002:a17:902:c40d:b0:199:67e:420f with SMTP id k13-20020a170902c40d00b00199067e420fmr194620plk.1.1675902256920; Wed, 08 Feb 2023 16:24:16 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id b20-20020a170902d89400b001992fc0a8eesm47302plz.174.2023.02.08.16.24.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Feb 2023 16:24:15 -0800 (PST) Date: Wed, 8 Feb 2023 16:24:13 -0800 From: Nathan Bossart To: Michael Paquier Cc: Robert Haas , Andres Freund , Tom Lane , Thomas Munro , Fujii Masao , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 Message-ID: <20230209002413.GA603595@nathanxps13> References: <20230205221938.GA274245@nathanxps13> <20230205230157.45kl5gqryupzdoyb@alap3.anarazel.de> <20230205235747.GA275913@nathanxps13> <20230206000750.ohqjmbfo3trtwvhc@alap3.anarazel.de> <20230206004631.GA277434@nathanxps13> <20230208174350.GB451849@nathanxps13> <20230208222554.GB546776@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 Thu, Feb 09, 2023 at 08:56:24AM +0900, Michael Paquier wrote: > On Wed, Feb 08, 2023 at 02:25:54PM -0800, Nathan Bossart wrote: >> These are all good points. Perhaps there could be a base archiver >> implementation that shell_archive uses (and that other modules could use if >> desired, which might be important for backward compatibility with the >> existing callbacks). But if you want to do something fancier than >> archiving sequentially, you could write your own. > > Which is basically the kind of things you can already achieve with a > background worker and a module of your own? IMO one of the big pieces that's missing is a way to get the next N files to archive. Right now, you'd have to trawl through archive_status on your own if you wanted to batch/parallelize. I think one advantage of what Robert is suggesting is that we could easily provide a supported way to get the next set of files to archive, and we can asynchronously mark them "done". Otherwise, each module has to implement this. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com