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 1nPblj-0005eK-Iq for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Mar 2022 03:04:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nPbli-00073D-3A for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Mar 2022 03:04:42 +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 1nPblh-000733-OV for pgsql-hackers@lists.postgresql.org; Thu, 03 Mar 2022 03:04:41 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nPblc-0006Rr-P1 for pgsql-hackers@lists.postgresql.org; Thu, 03 Mar 2022 03:04:40 +0000 Received: by mail-pj1-x1033.google.com with SMTP id gb21so3495812pjb.5 for ; Wed, 02 Mar 2022 19:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=gqeaI8l2l7cILabc9xj4VADdv7E1DP9VSWuqoH0aG0c=; b=MkAgD7xJGF9bgGcBHwhYqzJ9I/+bYSQSLpVr2Y9LLKF2O/2H1pNmHjtULR86kvrM8i troEHqvp/gcIP5whL4tLK4UEsQbXMl5bg4l4RDEDGVCsHCZzXKYh/Y9HvnONTLONuNtx sYOIoL8JVmyRvSUHbFADC01d1UMMoWDrtmYpd3Z9efdw+s4ObKB/cvNhTIpSgaRBev3v 5LlpQqmWri0jlmPI/TNJfEXE14UMI/f0pn23vdg0uIuHx34sOgBMhDOtUPHr+WJ3N1dP qiADRbb84gy0QF6yCJ0BsNWPrtrg8iqjcxdT3ptCoRTZmB+ldeMr2/b9BtcQa6k7sAOA 7/wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=gqeaI8l2l7cILabc9xj4VADdv7E1DP9VSWuqoH0aG0c=; b=qQwv4RAgSNwudGkZ7fiNofT0ebXMmDQfIc4L0mLmLCSzSmdXZ6f5RoKFS11r8TEMeO C+0z2ptpBxcISTy9katLDRDb6mUoZkOkwtdbgc/OzAgP5NyKhXKgg7CsQfpe76AlyGcU k3hZLZ79EGiN5Ly0DU3adTjYX8zT9CHAd75kxrbGQQbOkQCpbZmjkhsaAPV5TRXXh2/0 KKO+Q1XizDhWtgZe0er1vo80iNFNkyXtU7Sm4OxOkENmzoDzrxHoBkxcMyHGNGJxXPOz iffzP2Ku4r49WE1Zd24AG16Q7Hjaf03o/MAyMMzGifTqpUlrbpHVHdktNC+7XpSxipHO Fdfg== X-Gm-Message-State: AOAM531ymX/75KwONxKvegodVu0lUrrgRwf2EA3psAcWssmhAZ3lnTcl Amdj4lQjMYP6N8TM4Ua8xCo= X-Google-Smtp-Source: ABdhPJwa06nt1EN8B6HryxKP7LuBTmuf3m+pgAtd0z+c6YBbRo+M7nq3XoPCIawyoIadJU11r1jN+g== X-Received: by 2002:a17:90a:77c6:b0:1bd:5ce1:1966 with SMTP id e6-20020a17090a77c600b001bd5ce11966mr2978654pjs.230.1646276675683; Wed, 02 Mar 2022 19:04:35 -0800 (PST) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id f6-20020a654006000000b00346193b405fsm478432pgp.44.2022.03.02.19.04.33 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 02 Mar 2022 19:04:35 -0800 (PST) Date: Thu, 03 Mar 2022 12:04:32 +0900 (JST) Message-Id: <20220303.120432.2030688429524370234.horikyota.ntt@gmail.com> To: michael@paquier.xyz Cc: bharath.rupireddyforpostgres@gmail.com, nitinjadhavpostgres@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: Add CHECKPOINT_REQUESTED flag to the log message in LogCheckpointStart() From: Kyotaro Horiguchi In-Reply-To: References: <20220303.093937.2132907787383572158.horikyota.ntt@gmail.com> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Thu, 3 Mar 2022 10:27:10 +0900, Michael Paquier wrote in > On Thu, Mar 03, 2022 at 09:39:37AM +0900, Kyotaro Horiguchi wrote: > > At Wed, 2 Mar 2022 18:18:10 +0530, Bharath Rupireddy wrote in > >> I don't think that's useful. Being in LogCheckpointStart > >> (CreateCheckPoint or CreateRestartPoint) itself means that somebody > >> has requested a checkpoint. Having CHECKPOINT_REQUESTED doesn't add > >> any value. > > > > Agreed. > > Exactly my impression. This would apply now to the WAL shutdown code > paths, and I'd suspect that the callers of CreateCheckPoint() are not > going to increase soon. The point is: the logs already provide some > contexts for any of those callers so I see no need for this additional > information. > > > Actually no one does but RequestCheckpoint() accepts 0 as flags. > > Checkpointer would be a bit more complex without CHECKPOINT_REQUESTED. > > I don't think it does us any good to get rid of the flag value. > > I'd rather keep this code as-is. I fail to identify the nuance of the phrase, so just for a clarification. In short, I think we should keep the exiting code as-is. regards. -- Kyotaro Horiguchi NTT Open Source Software Center