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 1pNLi0-0004S2-IV for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 22:36:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNLhz-0002Wf-GT for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 22:36:03 +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 1pNLhz-0002WQ-4n for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 22:36:03 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pNLhw-0007sl-An for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 22:36:02 +0000 Received: by mail-pl1-x62a.google.com with SMTP id z1so5723plg.6 for ; Wed, 01 Feb 2023 14:36:00 -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=5Utv3JkvrRnXPZdnQ0cybj/Fgirff0xX1W+xuivJjZ8=; b=b8Vbcai6EH/vlypZJLZRoJtPXmjsgH5662GMqixsK4MdT6Au5n1/iA2srJ4BBWwqHV LjqBLdgzQFzu4GMcQIxeai6y8iFD8PA/J3A+myTal6a1SHV8UbpPnoO+cJE4qf2U74GM 8leuR80yXqfcTl+sdvnoMR6uPXWi1ZhIsjaozK19MT3MFfjb82/fGSc7AU7nJyRwV8K4 fAKnAsf4UkONueh0b+ztos2S4B/uKu5uU4TvoyTlFwqqBijrRh3r9mSdY+CmVe1j4HJs aVQWPi3uVEyyXRH4/wpMC85A0n0s8w6L2f0eK0JxrXmY3oEk+Tr6iESm0coOyr8a31ED CZbA== 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=5Utv3JkvrRnXPZdnQ0cybj/Fgirff0xX1W+xuivJjZ8=; b=CVBcb9dQy2Js0MmyN6VkmXZ289tzUfNglNleoy7u61n/MxNcVbV2wzIFNevf8K74aA BLADoG8hQSBY2t0T9IsEaVRl9cTdSimTchcXr5rhHzY/g4PhXvbZ1eYytDZZkpD8QBUM 3OJBVwm0pupSCotie6hwEuVnXkH/mfRMjM2WlTEYhludbvXjedKannhDaXbvO0PjjX/h RAKkzK7lB2qwkVLX2/k6GmCnvumceOaEH7x/Cl4nIGZGfM3TTSDs2dmMnu6D/moq3aSh btqX7Uc4kvkSunzo3M8mBtbuiR+SD43SWKsGaVB7EOJvKdRQLiZ+q+Ce+NzAWGHFx8TD LhQQ== X-Gm-Message-State: AO0yUKUAraqGBhD6W4q8oIDWUGVHzVsVmctFMWNpia8dFJkSkkdEbV94 IyYF8MbqCrnoG88PlXf5GwZ0byAXpWU= X-Google-Smtp-Source: AK7set98dNkqjP9Vx81LEb56TmTl2PsN2nd7ugPuu0+SpFIPZ086tNv7WQxRGDXjQrUPLvJ++YC7IA== X-Received: by 2002:a17:902:c943:b0:196:1cc3:74fb with SMTP id i3-20020a170902c94300b001961cc374fbmr4702640pla.50.1675290959078; Wed, 01 Feb 2023 14:35:59 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id e8-20020a170902744800b00197d19bbadbsm4626797plt.57.2023.02.01.14.35.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Feb 2023 14:35:58 -0800 (PST) Date: Wed, 1 Feb 2023 14:35:55 -0800 From: Nathan Bossart To: Andres Freund Cc: Tom Lane , Thomas Munro , Fujii Masao , Michael Paquier , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 Message-ID: <20230201223555.GA3721373@nathanxps13> References: <20230201021206.wobi3dsnnuany3yq@alap3.anarazel.de> <20230201105514.rsjl4bnhb65giyvo@alap3.anarazel.de> <1369666.1675264346@sss.pgh.pa.us> <20230201165801.33ydbxvjdbomjqa7@alap3.anarazel.de> <20230201175806.GA3199959@nathanxps13> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20230201175806.GA3199959@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 01, 2023 at 09:58:06AM -0800, Nathan Bossart wrote: > On Wed, Feb 01, 2023 at 08:58:01AM -0800, Andres Freund wrote: >> On 2023-02-01 10:12:26 -0500, Tom Lane wrote: >>> 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. >> >> We could push the functions setting in_restore_command down into >> ExecuteRecoveryCommand(). But I don't think that'd end up necessarily >> being right either - we'd now use the mechanism in places we previously >> didn't (cleanup/end commands). > > Right, we'd only want to set it for restore_command. I think that's > doable. Here is a first draft for the proposed stopgap fix. If we want to proceed with this, I can provide patches for the back branches. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com --nFreZHaLTZJo0R7j Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-stopgap-fix-for-restore_command.patch" From c703a9f7ac6c43e65fc32117980495ac7980e2e3 Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Wed, 1 Feb 2023 14:32:02 -0800 Subject: [PATCH v1 1/1] stopgap fix for restore_command --- src/backend/access/transam/shell_restore.c | 22 ++++++++++++++++++++-- src/backend/access/transam/xlogarchive.c | 7 ------- 2 files changed, 20 insertions(+), 9 deletions(-) diff --git a/src/backend/access/transam/shell_restore.c b/src/backend/access/transam/shell_restore.c index 8458209f49..abec023c1a 100644 --- a/src/backend/access/transam/shell_restore.c +++ b/src/backend/access/transam/shell_restore.c @@ -21,6 +21,7 @@ #include "access/xlogarchive.h" #include "access/xlogrecovery.h" #include "common/percentrepl.h" +#include "postmaster/startup.h" #include "storage/ipc.h" #include "utils/wait_event.h" @@ -124,8 +125,7 @@ shell_recovery_end(const char *lastRestartPointFileName) * human-readable name describing the command emitted in the logs. If * 'failOnSignal' is true and the command is killed by a signal, a FATAL * error is thrown. Otherwise, 'fail_elevel' is used for the log message. - * If 'exitOnSigterm' is true and the command is killed by SIGTERM, we exit - * immediately. + * If 'exitOnSigterm' is true and SIGTERM is received, we exit immediately. * * Returns whether the command succeeded. */ @@ -146,7 +146,25 @@ ExecuteRecoveryCommand(const char *command, const char *commandName, */ fflush(NULL); pgstat_report_wait_start(wait_event_info); + + /* + * PreRestoreCommand() is used to tell the SIGTERM handler for the startup + * process that it is okay to proc_exit() right away on SIGTERM. This is + * done for the duration of the system() call because there isn't a good + * way to break out while it is executing. Since we might call proc_exit() + * in a signal handler here, it is extremely important that nothing but the + * system() call happens between the calls to PreRestoreCommand() and + * PostRestoreCommand(). Any additional code must go before or after this + * section. + */ + if (exitOnSigterm) + PreRestoreCommand(); + rc = system(command); + + if (exitOnSigterm) + PostRestoreCommand(); + pgstat_report_wait_end(); if (rc != 0) diff --git a/src/backend/access/transam/xlogarchive.c b/src/backend/access/transam/xlogarchive.c index 4b89addf97..66312c816b 100644 --- a/src/backend/access/transam/xlogarchive.c +++ b/src/backend/access/transam/xlogarchive.c @@ -147,18 +147,11 @@ RestoreArchivedFile(char *path, const char *xlogfname, else XLogFileName(lastRestartPointFname, 0, 0L, wal_segment_size); - /* - * Check signals before restore command and reset afterwards. - */ - PreRestoreCommand(); - /* * Copy xlog from archival storage to XLOGDIR */ ret = shell_restore(xlogfname, xlogpath, lastRestartPointFname); - PostRestoreCommand(); - if (ret) { /* -- 2.25.1 --nFreZHaLTZJo0R7j--