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 1pNFcn-0000De-C7 for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 16:06:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNFcm-0000KQ-7I for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 16:06:16 +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 1pNFcl-0000Jb-Tm for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 16:06:15 +0000 Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pNFci-0004Pt-F2 for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 16:06:14 +0000 Received: by mail-pf1-x42d.google.com with SMTP id z1so9935140pfg.12 for ; Wed, 01 Feb 2023 08:06:12 -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=OIFNiazO3Vhx6h/n60DswpknnhIA3zRhcpDaWdtVuSw=; b=fo7DPw7LkzB+xx0LSSrCXdQUkUuKnkZ5S/O9eJQVY55TIgO2ZsNo3gWoqQYEAnwxgp DlGp0nb5Nb3diOA8tKh+eAaS+E1j2HIIiqzly6Wh11DgztFIhxFV1knWT5xAF1EmOjnj rSSda//LYMScofexIBwRhUpVpXjkuPsWrnhJXQ9PD7li0Rj1nmUfWiribRm8UZ5X6yGk ztKe+dkgkKgZYtmFtj5GBp7mVaO/vrTrUouKz7iO1UtwBWaJA6YpaRtaSR0gDvvcPOOF gu6wESY581b+ashAxxkdtfeuFLbJkikAPO3Nem7R5Gxu4ebUE8cTnCSazlmXK43kRSD3 g2cg== 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=OIFNiazO3Vhx6h/n60DswpknnhIA3zRhcpDaWdtVuSw=; b=jAN6DMmA2Ko3LnogDzL3KjZF3eeXRe/LnQIsWdDuJnjY/4VqO3Zr7GoEIg5Zjq9CyW T4Jih+WDgtzEugTG10pxRdLckSH9q1i/nNd6BIsQzd4zKvbXBt1pi5WDChObXPJ13SgN kccqw+CrGaaNWoZ359fQaYsTeDkEY6kC6PbgUmhW/aT1kjFp6ZTi7HXwX+wLx7tXuKTB juCag2hYNTKXl/BLn6wMIHZVxnnWXGFsAj9I+FGH9cXvGXOlNR69oY4tOG5oS7F8boSu DHeewzhjeQ8LSF5noPkXpfTSUk0xBTONLSgT9xtBDFtkYkVM1rCgBQTRyAGsKIKTTh26 D83g== X-Gm-Message-State: AO0yUKUBtDsxoAyebcT5t95xZZf/lIWHyTt2KJ4JQWtQZVJgF6s6jtsj X6DjVmj5sHZfFI04cHhGp8k= X-Google-Smtp-Source: AK7set8wvmKu348tjEXTN9sBVcPiM3kFAKbhfLOfQP3dedD2CjQaG6dlJp2XsOFoBnq4mM8IsS/F/Q== X-Received: by 2002:aa7:9548:0:b0:58d:aae3:bcc1 with SMTP id w8-20020aa79548000000b0058daae3bcc1mr3581211pfq.5.1675267571436; Wed, 01 Feb 2023 08:06:11 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id dw7-20020a056a00368700b00593cd0f37dcsm5713612pfb.169.2023.02.01.08.06.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Feb 2023 08:06:10 -0800 (PST) Date: Wed, 1 Feb 2023 08:06:09 -0800 From: Nathan Bossart To: Tom Lane Cc: Andres Freund , Thomas Munro , Fujii Masao , Michael Paquier , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 Message-ID: <20230201160609.GA3197588@nathanxps13> References: <20230201021206.wobi3dsnnuany3yq@alap3.anarazel.de> <20230201105514.rsjl4bnhb65giyvo@alap3.anarazel.de> <1369666.1675264346@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1369666.1675264346@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Feb 01, 2023 at 10:12:26AM -0500, Tom Lane wrote: > Andres Freund writes: >> On 2023-02-01 16:21:16 +1300, Thomas Munro wrote: >>> It's always in proc_exit() in StartupProcShutdownHandler(), a SIGTERM >>> handler which is allowed to call that while in_restore_command is >>> true. > >> Ugh, no wonder we're getting crashes. This whole business seems bogus as >> hell. > > Indeed :-( Ugh. My bad. > The fundamental issue is that we have no good way to break out > of system(), and I think the original idea was that > in_restore_command would be set *only* for the duration of the > system() call. That's clearly been lost sight of completely, > but maybe as a stopgap we could try to get back to that. +1. I'll produce some patches. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com