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 1pOotS-00076f-2v for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Feb 2023 23:57:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pOotQ-0001bX-Jg for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Feb 2023 23:57:56 +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 1pOotQ-0001bN-99 for pgsql-hackers@lists.postgresql.org; Sun, 05 Feb 2023 23:57:56 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pOotM-0001Cl-Mu for pgsql-hackers@lists.postgresql.org; Sun, 05 Feb 2023 23:57:55 +0000 Received: by mail-pj1-x102b.google.com with SMTP id bx22so7166406pjb.3 for ; Sun, 05 Feb 2023 15:57: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=gwkSojSuzHBLulvWxMg/NgvvrglUhd/DHH4zH0M0GAk=; b=DtlXAe40V06M7qlA1ynb/yvNMIVsv7spquP3TRFNe1nHOlraS0TLrC32m9kAhFs667 RpBMs/oVA4/fomBscj3gxtfV03qtgfMIZKhpxmPrWqkKrT6BOc/VbpRHx//WBc02+QIJ MMHqoZHeOq6iq+8RvbBVsncrT5WiRFg9siQGut+ZLqxH9zsYbcexy0/QfGICGXFwmvaT 8vNrJUg+BX/kxC3FECxJ22Of2otC+J4KD9QCNqzbQZw/5KK7LDSYhS4PtosXWIQemTcE O4WHjjnl7Dbf2/EEpmTCuyOeNIL1j/bm+4PC9mVaeRzG8M8PrXglOw/X1kH+q8OPIox0 9plg== 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=gwkSojSuzHBLulvWxMg/NgvvrglUhd/DHH4zH0M0GAk=; b=eZfOPKR5YcfRaX6WYbCV5fnW2PEFEq5QyxHnIsCYu/tcQT1C5i8JX6H1uS+SNPVLL1 z8dJf4zv1U9vEbrm7KUv5j4siucxeR7MQbD7PuzS+lDZd0UF1fk0ze0R1BD6e4dRrUrV 6uocnRBLFuA37HxIyO31CkkwDxQsP2P5NLHoqEaBktX1NySbpYziftQvQYr+ELPEmS6S IZbrleMEYq2CDh0u/BZC/LuyahBextR4G0jUgo5GaKKhjrH3UVlX7i739bIywpwvlgn+ ADvu3TC9b/oOJET7Ec7DYzOuPJkrhPzRKMIH4jEEUNKqmamPz04TCv3pTYTvjq/N4h0P 5abQ== X-Gm-Message-State: AO0yUKWoSBQqgNA9Bsr7dk7Li3Wcehwh++FAoLL3tbeTepCmgOb3fRnL LJ5IwTYamammP/rjuwxsheA= X-Google-Smtp-Source: AK7set+w05aqHQxx69FcCvlomKhU9N1kYSM/DKs9E2abSqCSdKme6DA2Z0reGVkv3mmj3ns1i3fvSg== X-Received: by 2002:a17:902:c94c:b0:196:58ac:6593 with SMTP id i12-20020a170902c94c00b0019658ac6593mr22890512pla.61.1675641470653; Sun, 05 Feb 2023 15:57:50 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id k3-20020a170902ce0300b00198d1993b4esm5444039plg.69.2023.02.05.15.57.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Feb 2023 15:57:49 -0800 (PST) Date: Sun, 5 Feb 2023 15:57:47 -0800 From: Nathan Bossart To: Andres Freund Cc: Michael Paquier , Tom Lane , Thomas Munro , Fujii Masao , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 Message-ID: <20230205235747.GA275913@nathanxps13> References: <1369666.1675264346@sss.pgh.pa.us> <20230201165801.33ydbxvjdbomjqa7@alap3.anarazel.de> <20230201175806.GA3199959@nathanxps13> <20230201223555.GA3721373@nathanxps13> <20230204113029.xlcqrbxhp6lerrnc@alap3.anarazel.de> <20230204180354.GA258107@nathanxps13> <20230205221938.GA274245@nathanxps13> <20230205230157.45kl5gqryupzdoyb@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230205230157.45kl5gqryupzdoyb@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Feb 05, 2023 at 03:01:57PM -0800, Andres Freund wrote: > I think at the very least you'd want to have a separate callback for > restoring segments than for restoring other files. But more likely a > separate callback for each type of file to be restored. > > For the timeline history case an parameter indicating that we don't want > to restore the file, just to see if there's a conflict, would make > sense. That seems reasonable. > For the segment files, we'd likely need a parameter to indicate whether > the restore is random or not. Wouldn't this approach still require each module to handle restoring ahead of time? I agree that the shell overhead isn't the main performance issue, but it's unclear to me how much of this should be baked into PostgreSQL. I mean, we could introduce a GUC that tells us how far ahead to restore and have a background worker (or multiple background workers) asynchronously pull files into a staging directory via the callbacks. Is that the sort of scope you are envisioning? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com