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 1pQAdj-0002M8-1q for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 17:23: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 1pQAdh-0003ta-AF for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 17:23:17 +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 1pQAdg-0003tR-V9 for pgsql-hackers@lists.postgresql.org; Thu, 09 Feb 2023 17:23:17 +0000 Received: from mail-pg1-x530.google.com ([2607:f8b0:4864:20::530]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pQAde-0006Bj-AW for pgsql-hackers@lists.postgresql.org; Thu, 09 Feb 2023 17:23:16 +0000 Received: by mail-pg1-x530.google.com with SMTP id 7so2045181pga.1 for ; Thu, 09 Feb 2023 09:23:13 -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=76v68QNqA3GS5+H6KtYRUqr8vN1e6+/yFo3usV5LsFY=; b=hSofVogS/fhpmnhJaIT2q/NZHfTGOUlKACEt+6zAkP8ftE+gU0NygZKjrNbRlQT4PJ 9+/7LtsZ5yQwvlTC7k3t1JOc0lTKOI7pQDytdMknJDlpE2P0wts/CQwBEZp5jukRZUot ql2IDOrV/5Q/I3v3OyeBpPPh1Go4domSEZDwMQW0r73jOC5c6HqBW5u0NuiOiVzmEZ+i oZS8OsElHMQyJBLAIlUqBbmONUBG6P+8ASQ4ntLkk2OIx1Ery2looXYwQgok1e+sDeSX bEuGZkvYncjEMl3BSMF5Iw09oZ5cf+PfPvgRYRTd3NeE3abn2axTVw+1MclFdaOKWNom PZ1A== 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=76v68QNqA3GS5+H6KtYRUqr8vN1e6+/yFo3usV5LsFY=; b=wfDzpg0xt1n48S2aT83SBJolNFA5POiF0i+blE4HCtP++DMPA3zPAWNDKZ8fSvPxoE NeY6zOSJIA2w6io7aMMlG4z2XAvK9Y0QMLetDyntvbFxfnXzNz287qx4s3eyrpH4uF2R HWmuOiYYFaIq9+j5bruCqBFzPklQMCX+h5m453nLo2C31ha5wTvSAlhDZrJx2cKidIx2 nM1cKALlTbtZ7dGOkHCzHcbO0/s4hWb9ZjwicgnkAxugXFEw7CWvSNjJQDhsE/9eSkn0 VIn3e8ed9XTK4ovjCAXrtvxmh3CwJu1RFlO6xTiCr9gkvG9KFnYNyVtoD/b2LQkeLyk1 yQKA== X-Gm-Message-State: AO0yUKUv8Nh3XxtV7kqsNHEdDpKt7PjMkdHyTneaWnhb+KjBq256p3n1 LTXhIMmuSJ6EOk0jHhXnq5s= X-Google-Smtp-Source: AK7set8jaYS7eI403ZGKilGtRonVDlB57JjzswoBUD2pefCxxGtygvTTYsu76fDXAbgQQqORftKoCQ== X-Received: by 2002:a62:8451:0:b0:5a8:4428:246f with SMTP id k78-20020a628451000000b005a84428246fmr6507238pfd.16.1675963392021; Thu, 09 Feb 2023 09:23:12 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id j7-20020aa78dc7000000b00593adee79efsm1699594pfr.55.2023.02.09.09.23.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 09:23:11 -0800 (PST) Date: Thu, 9 Feb 2023 09:23:08 -0800 From: Nathan Bossart To: Robert Haas Cc: Tom Lane , Michael Paquier , Andres Freund , Thomas Munro , Fujii Masao , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 Message-ID: <20230209172308.GA605342@nathanxps13> References: <20230206004631.GA277434@nathanxps13> <20230208174350.GB451849@nathanxps13> <20230208222554.GB546776@nathanxps13> <20230209002413.GA603595@nathanxps13> <3907196.1675957889@sss.pgh.pa.us> 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 11:12:21AM -0500, Robert Haas wrote: > On Thu, Feb 9, 2023 at 10:51 AM Tom Lane wrote: >> 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. > > I don't quite see how you can make asynchronous and parallel archiving > work if the archiver process only calls into the archive module at > times that it chooses. That would mean that the module has to return > control to the archiver when it's in the middle of archiving one or > more files -- and then I don't see how it can get control back at the > appropriate time. Do you have a thought about that? I've been thinking about this, actually. I'm wondering if we could provide a list of files to the archiving callback (configurable via a variable in ArchiveModuleState), and then have the callback return a list of files that are archived. (Or maybe we just put the list of files that need archiving in ArchiveModuleState.) The returned list could include files that were sent to the callback previously. The archive module would be responsible for creating background worker(s) (if desired), dispatching files to-be-archived to its background worker(s), and gathering the list of archived files to return. This is admittedly half-formed, but I'm tempted to hack something together quickly to see whether it might be viable. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com