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 1kbOmm-0008Mc-4L for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Nov 2020 14:01:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kbOmj-000356-Nd for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Nov 2020 14:01:41 +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 1kbOmj-00034z-EE for pgsql-hackers@lists.postgresql.org; Sat, 07 Nov 2020 14:01:41 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kbOmc-0004Su-Ep for pgsql-hackers@postgresql.org; Sat, 07 Nov 2020 14:01:41 +0000 Received: by mail-pl1-x62c.google.com with SMTP id x15so1488014pll.2 for ; Sat, 07 Nov 2020 06:01:34 -0800 (PST) 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; bh=G3P+++91yiwZIyvMtlNzsHhpr4HFgsjFqQE+C8Z4mow=; b=OM4ieKiT7M/xB7xitBm4VHgToIiGxtnol8E6nDAZ/8clsuVBMTT3zObufqalnlMTfb W4yVuiuzHWHRy1htLo1/NDCARsJgXtqCHxQxGShFSpiCFusl2KEE5vDFxn5MqAuyyG3I 6ZfnLYiNazhJ+uExr9Ria8HPPw34eC7Sv8Z7tEPFNDgOZ713Zv7qCvTP390IhoBxkU2s 7MB4uUef15yqdAt2BEMuP9Ip3s4aW64Zeorch3b3nU8AegiW+Lep6iqYPJu/96X5Xs+v hADxg550F34p6fomTevfnaFj4goZz2smzRosYQ6+SNyHg9JM24hrTHO/jtefBJwFNV7O 3lnQ== 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; bh=G3P+++91yiwZIyvMtlNzsHhpr4HFgsjFqQE+C8Z4mow=; b=ZpCyUoOcNn+T/saRvvCkYKzD9xcDepdvfRi1ii0MKkRxf2AuCLC58Gq7ehGYN1g/s5 j/dbsw1p/kCG4H/C6t9qr1seilhGZ7dPXmeYnO6noXpQcCZIT9qSOo10+KUs51VPg0vt Knszw/cwrcbBtGsyAguhp5qEja4UJ2gjiBhdKKWMNlRq5DwVU6qefZpWI49EZHcwflRy pOotNiEo+rTxh+e5XqmqSnoM1twTRANKykEpMQxRkwe/gzYCZktpFTgfwfKat50fNdFi Lb6vJskdnwtWrEtebMB+ICP94e0lJgr/fAfFeEhaKseFJPvKuK4GRF6xIQlqX/CbF6/s sCoA== X-Gm-Message-State: AOAM533hM++A9Zy34dvpK5xS7mTsyMEcOG1NngJ28zhPHB95/cLdeSvR KiTQkn1+3f4zkwAkK/5aV0swtMzOAXksinqPtFY= X-Google-Smtp-Source: ABdhPJz6lH2GT48ZzvWnxsI3eXwrN/wflWPPBC8gwxvca1wZDnFNC/a8R/Wkp++zz8SZ93+FpyKJ9EvgbYewQDVYm4Y= X-Received: by 2002:a17:902:788e:b029:d6:9a57:ccab with SMTP id q14-20020a170902788eb02900d69a57ccabmr2603876pll.41.1604757692062; Sat, 07 Nov 2020 06:01:32 -0800 (PST) MIME-Version: 1.0 References: <6b561c73-27ce-7079-b6e5-440e49653810@oss.nttdata.com> <20201105.121206.819769369617763972.horikyota.ntt@gmail.com> In-Reply-To: From: Bharath Rupireddy Date: Sat, 7 Nov 2020 19:31:21 +0530 Message-ID: Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module To: Fujii Masao Cc: Kyotaro Horiguchi , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Nov 6, 2020 at 11:00 PM Fujii Masao wrote: > > >> I'm not quite sure to replace all the places in the walreceiver > >> process, for instance in WalRcvForceReply() we are using spinlock to > >> acquire the latch pointer and . Others may have better thoughts on > >> this. > > > > The SIGTERM part looks good. The only difference between > > WalRcvSigHupHandler and SignalHandlerForConfigReload is whether latch > > is set or not. I don't think it's a problem that config-reload causes > > an extra wakeup. Couldn't we do the same thing for SIGHUP? > > I agree that we can use even standard SIGHUP handler in walreceiver. > I'm not sure why SetLatch() was not called in walreceiver's SIGHUP > handler so far. > The main reason for having SetLatch() in SignalHandlerForConfigReload() is to wake up the calling process if waiting in WaitLatchOrSocket() or WaitLatch() and reload the new config file and use the reloaded config variables. Maybe we should give a thought on the scenarios in which the walreceiver process waits, and what happens in case the latch is set when SIGHUP is received. And also, I think it's worth having a look at the commit 40f908bdcdc7 that introduced WalRcvSigHupHandler() and 597a87ccc that replaced custom latch with procLatch. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com