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 1lrHVG-00022V-BA for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Jun 2021 10:01:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lrHVF-00059J-0u for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Jun 2021 10:01:33 +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 1lrHVE-00058s-MA for pgsql-hackers@lists.postgresql.org; Thu, 10 Jun 2021 10:01:32 +0000 Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lrHVC-000168-82 for pgsql-hackers@postgresql.org; Thu, 10 Jun 2021 10:01:32 +0000 Received: by mail-io1-xd32.google.com with SMTP id k5so16404875iow.12 for ; Thu, 10 Jun 2021 03:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=D3AJlorGmY0QcvyRsFLW+2aPv6MTzCDJhFPjYgtHNfU=; b=gtUwuk1F9lacvHfSjIteyQIouuDEOPT5j9dORDgpxDMgvA8e8Aolij9/Ygka65hRsR qWr2dYk3jXRPB9zTDI0zl2t087Q4YuwOmyB+Vvo6gCjvUoeMzqEn9MY9ZjzRPyliTXl9 8ZqbXrnKH1CWMrti+FkMjwi4lHpOZSt/BiybX+N2c9vc+tLGMSwX4RwvB17paDdksJyD nJjL5hjzOqYNUTAn21H7WUMclA8I0M0xzqBMTk4gJDQvC4oY4NdSIqbRfLkbNOLEw+4k XD+RBFxqFuW346X5zhbGOTS29MLAGJdISa7JCi9bgKSWqAArQ9YfVYy1JLZj8uXRvWyw J9nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=D3AJlorGmY0QcvyRsFLW+2aPv6MTzCDJhFPjYgtHNfU=; b=fHXL16x7yuBGMuad6G1/F4CI9epQJf2aELdqZK0hrsKStYuLJeze11uhq260DMDVkg C/ZKggSAOVbil1idBPcJoyfox9uWcHE2gmHowHg+GUXR+CW6BdAuhRpZ3NgVWL3g1KKc fAipnfezCTLc4Eztb0lVoayzn4INfmpGO3LxrFXcALaHhO+jeM7rsKKJtHxvVv3Bjy2p jYeC42D/rZ3AhTqXK3OKWAHW1xrm3eJhxX41Z8mzc/3C/YbLQ1sZTuCUYYUwxTtZ5nuS NzpnzcQjGFUNO4ZNjNqMzIPMM2Yz7aLZtF7qsj6zCRVyYvmWWY9XIHWMu9EGv6Pw/oMZ MrWQ== X-Gm-Message-State: AOAM5337XCzACouSdyuIXy5qDJPT1wb9DLqKn1ufKfk6YrpPhs/+NF4A 2caLwUoLe4836XSmzEqQgMgoaw== X-Google-Smtp-Source: ABdhPJxRizFWx64RiFu/8UhQWs6L1tXflCz8XG5H8j1SOS9MR+PbS4p9YBjjS0lIQ3uQJ6QFIjq+BA== X-Received: by 2002:a5d:9842:: with SMTP id p2mr3200716ios.132.1623319287851; Thu, 10 Jun 2021 03:01:27 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id u5sm1340473iob.44.2021.06.10.03.01.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jun 2021 03:01:27 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id C4D9880090D; Thu, 10 Jun 2021 05:01:25 -0500 (CDT) Date: Thu, 10 Jun 2021 05:01:25 -0500 From: Justin Pryzby To: Nitin Jadhav Cc: Tom Lane , Robert Haas , Andres Freund , Stephen Frost , Magnus Hagander , Thomas Munro , Pg Hackers Subject: Re: when the startup process doesn't Message-ID: <20210610100125.GE16435@telsasoft.com> References: <20210421183624.GP20766@tamriel.snowman.net> <20210421193605.cubavrq7q5bqkf4i@alap3.anarazel.de> <20210422010919.4b655015@firost> <20210606222305.GZ14099@telsasoft.com> <867286.1623073349@sss.pgh.pa.us> <20210609161918.GY16435@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Jun 10, 2021 at 03:19:20PM +0530, Nitin Jadhav wrote: > > > > + {"log_min_duration_startup_process", PGC_SUSET, LOGGING_WHEN, > > > > > > > > I think it should be PGC_SIGHUP, to allow changing it during runtime. > > > > Obviously it has no effect except during startup, but the change will be > > > > effective if the current process crashes. > > > > See also: https://www.postgresql.org/message-id/20210526001359.GE3676@telsasoft.com > > > > > > I did not get exactly how it will change behaviour. In my > > > understanding, when the server restarts after a crash, it fetches the > > > value from the config file. So if there is any change that gets > > > affected. Kindly correct me if I am wrong. > > Sorry my understanding was wrong. But I'm not completely convinced > with the above description saying that the change will be effective if > the current process crashes. > AFAIK, whenever we set the GucContext less than PGC_SIGHUP (that is > either PGC_POSTMASTER or PGC_INTERNAL) then any change in the config > file will not get affected during restart after crash. If the > GucContext is greater than or equal to PGC_SIGHUP, then any change in > the config file will be changed once it receives the SIGHUP signal. So > it gets affected by a restart after a crash. So since the GucContext > set here is PGC_SUSET which is greater than PGC_SIGHUP, there is no > change in the behaviour wrt this point. Since you agreed that SUSET was wrong, and PGC_POSTMASTER doesn't allow changing the value without restart, doesn't it follow that SIGHUP is what's wanted ? > > I've triple checked the behavior using a patch I submitted for Thomas' syncfs > > feature. ALTER SYSTEM recovery_init_sync_method=syncfs was not picked up when > > I sent SIGABRT. But with my patch, if I also do SELECT pg_reload_conf(), then > > a future crash uses syncfs. > > https://www.postgresql.org/message-id/20210526001359.GE3676@telsasoft.com > > The difference is since the behaviour is compared between > PGC_POSTMASTER and PGC_SIGHUP. > > > The GUC definitely isn't SUSET, since it's not useful to write in a (super) > > user session SET log_min_duration_startup_process=123. > I agree with this. I may have to change this value as setting in a > user session is not at all useful. But I am confused between > PGC_POSTMASTER and PGC_SIGHUP. We should use PGC_SIGHUP if we would > like to allow the change during restart after a crash. Otherwise > PGC_POSTMASTER would be sufficient. Kindly share your thoughts. > > Thanks & Regards, > Nitin Jadhav > > On Wed, Jun 9, 2021 at 9:49 PM Justin Pryzby wrote: > > > > On Wed, Jun 09, 2021 at 05:09:54PM +0530, Nitin Jadhav wrote: > > > > + {"log_min_duration_startup_process", PGC_SUSET, LOGGING_WHEN, > > > > > > > > I think it should be PGC_SIGHUP, to allow changing it during runtime. > > > > Obviously it has no effect except during startup, but the change will be > > > > effective if the current process crashes. > > > > See also: https://www.postgresql.org/message-id/20210526001359.GE3676@telsasoft.com > > > > > > I did not get exactly how it will change behaviour. In my > > > understanding, when the server restarts after a crash, it fetches the > > > value from the config file. So if there is any change that gets > > > affected. Kindly correct me if I am wrong. > > > > I don't think so. I checked and SelectConfigFiles is called only once to read > > config files and cmdline args. And not called on restart_after_crash. > > > > The GUC definitely isn't SUSET, since it's not useful to write in a (super) > > user session SET log_min_duration_startup_process=123. > > > > I've triple checked the behavior using a patch I submitted for Thomas' syncfs > > feature. ALTER SYSTEM recovery_init_sync_method=syncfs was not picked up when > > I sent SIGABRT. But with my patch, if I also do SELECT pg_reload_conf(), then > > a future crash uses syncfs. > > https://www.postgresql.org/message-id/20210526001359.GE3676@telsasoft.com