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 1pQ9Ed-0006xw-EI for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 15:53:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pQ9Ec-00014r-91 for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 15:53:18 +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 1pQ9Cx-0003hY-RP for pgsql-hackers@lists.postgresql.org; Thu, 09 Feb 2023 15:51:35 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pQ9Cv-0005B6-QA for pgsql-hackers@lists.postgresql.org; Thu, 09 Feb 2023 15:51:35 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 319FpTiA3907197; Thu, 9 Feb 2023 10:51:29 -0500 From: Tom Lane To: Robert Haas cc: Nathan Bossart , Michael Paquier , Andres Freund , Thomas Munro , Fujii Masao , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 In-reply-to: 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> <20230209002413.GA603595@nathanxps13> Comments: In-reply-to Robert Haas message dated "Thu, 09 Feb 2023 09:22:31 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3907195.1675957889.1@sss.pgh.pa.us> Date: Thu, 09 Feb 2023 10:51:29 -0500 Message-ID: <3907196.1675957889@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > I think that we could certainly, as Michael suggests, have people > provide their own background worker rather than having the archiver > invoke the user-supplied code directly. As long as the functions that > you need in order to get the necessary information can be called from > some other process, that's fine. The only difficulty I see is that if > the archiving is happening from a separate background worker rather > than from the archiver, then what is the archiver doing? We could > somehow arrange to not run the archiver process at all, or I guess to > just sit there and have it do nothing. Or, we can decide not to have a > separate background worker and just have the archiver call the > user-supplied core directly. I kind of like that approach at the > moment; it seems more elegant to me. I'm fairly concerned about the idea of making it common for people to write their own main loop for the archiver. That means that, if we have a bug fix that requires the archiver to do X, we will not just be patching our own code but trying to get an indeterminate set of third parties to add the fix to their code. If we think we need primitives to let the archiver hooks get all the pending files, or whatever, by all means add those. But don't cede fundamental control of the archiver. The hooks need to be decoration on a framework we provide, not the framework themselves. regards, tom lane