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 1kPTC8-0002gs-Bu for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Oct 2020 16:18:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kPTC7-00067u-8W for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Oct 2020 16:18:35 +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 1kPTC7-00065o-1p for pgsql-hackers@lists.postgresql.org; Mon, 05 Oct 2020 16:18:35 +0000 Received: from mail-ed1-x543.google.com ([2a00:1450:4864:20::543]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kPTC4-0005LM-Pk for pgsql-hackers@postgresql.org; Mon, 05 Oct 2020 16:18:34 +0000 Received: by mail-ed1-x543.google.com with SMTP id p13so4074639edi.7 for ; Mon, 05 Oct 2020 09:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EF5+KIMvyC+sDqQxQlWjSVxipuHRfHBpZvjI/Obr1Zg=; b=hv8w8/sLR3yYRAgR6r038vlRwl9qm75WXZvix2gjyruiZnVMsV3tPJqgKIPK5inNvB 6NbWa+Kz7M558RRLNlsaoFheIci1iqXwsbaR2PC1jwR1VuS5faZGkZ8oGScw94eFAg2f H0x1ru/enOGlHatg3uCx4yj2LvVsJEanPogM0sNhxHEuUZegUpwQWy3JJ8nB+elgIzNL Lz3pSoZrpYe2H7selzyGGdqAfNuaD85AnffXWqOjzgk3sNp7dkMO+S4DnvBB6CxjiBxS hzUh2AGYFx5fstFRTaSYf6OtnwfddPzd/E26Ap7L5e6Z2E5u+t5Lc+R5Zz+/6UaRCA8a 4JAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EF5+KIMvyC+sDqQxQlWjSVxipuHRfHBpZvjI/Obr1Zg=; b=LaU5+JUBW0ftcTPWTUNXIGn9O/tox4W9suMd0wy0vdGGw9IK2LiswnqfeJo/QYfJmN UC/eCC7gei5ltPV/02yetVMCTs07yf4ASmetO+LU4ZcFtxS5ujWgb79TrBO/nRCoo9B5 9HB5ThGPPF7DHXg+5AXBFsRfKkGxk/c4k0tBBC59AooEoD/+HZFHnwhAhee0Dpk0qRfC MC152jr68QAFty33E59GT7caTRrEzYnG5zKlWs4kyOGnW5Ipgi2VoWH960nwDO+bJ4aI m5HVxxOq0JApi+py0zOdoErFY+lKzV2NH3nBvl4f5u+YKOXmysy3NVpeYDPQwgOLRJXw xujw== X-Gm-Message-State: AOAM533NCv8z4vH9SBDUm4ODe8PlFKi93mgWA/xVCp6Ib+wEZj9VUsEO vydZX7bmGTVL0Ahy0zVnK7di8Ss5hugsdYhgzJK5ebnFvYE= X-Google-Smtp-Source: ABdhPJxe2fg85rZxqXrD8zCxUX7r+LOLFRGWK7dTgIw4yyr7hK67fkNVpo3gYIHr+EIWtwyLUk4Dk9TOL1ZF1c75cYk= X-Received: by 2002:a50:fc0d:: with SMTP id i13mr443436edr.122.1601914711148; Mon, 05 Oct 2020 09:18:31 -0700 (PDT) MIME-Version: 1.0 References: <13156732-5189-af54-3d28-e2ee2a8568e0@oss.nttdata.com> In-Reply-To: <13156732-5189-af54-3d28-e2ee2a8568e0@oss.nttdata.com> From: Bharath Rupireddy Date: Mon, 5 Oct 2020 21:48:19 +0530 Message-ID: Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module To: Fujii Masao Cc: PostgreSQL-development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Oct 5, 2020 at 8:04 PM Fujii Masao wr= ote: > > On 2020/10/05 19:45, Bharath Rupireddy wrote: > > Hi, > > > > Autoprewarm module is using it's own SIGHUP(apw_sigterm_handler, got_si= gterm) and SIGTERM(apw_sighup_handler, got_sighup) handlers which are simil= ar to standard signal handlers(except for a difference [1]). Isn't it good = to remove them and use standard SignalHandlerForConfigReload and SignalHan= dlerForShutdownRequest? > > > > Attaching the patch for the above changes. > > > > Looks like the commit[2] replaced custom handlers with standard handler= s. > > > > Thoughts? > > +1 > > The patch looks good to me. > Thanks. > > ISTM that we can also replace StartupProcSigHupHandler() in startup.c > with SignalHandlerForConfigReload() by making the startup process use > the general shared latch instead of its own one. POC patch attached. > Thought? > I'm not quite sure whether it breaks something or not. I see that WakeupRecovery() with XLogCtl->recoveryWakeupLatch latch from the startup process is also being used in the walreceiver process. I may be wrong, but have some concern if the behaviour is different in case of EXEC_BACKEND and Windows? Another concern is that we are always using XLogCtl->recoveryWakeupLatch in shared mode, this makes sense as this latch is also being used in walrecevier. But sometimes, MyLatch is created in non-shared mode as well(see InitLatch(MyLatch)). Others may have better thoughts though. > > Probably we can also replace sigHupHandler() in syslogger.c with > SignalHandlerForConfigReload()? This would be separate patch, though. > +1 to replace sigHupHandler() with SignalHandlerForConfigReload() as the latch and the functionality are pretty much the same. WalReceiverMai(): I think we can also replace WalRcvShutdownHandler() with SignalHandlerForShutdownRequest() because walrcv->latch point to &MyProc->procLatch which in turn point to MyLatch. Thoughts? If okay, we can combine these into a single patch. I will post an updated patch soon. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com