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 1nANgx-0003yl-Di for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 03:00:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nANgv-0001kp-WA for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 03:00:49 +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 1nANgv-0001kg-LK for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 03:00:49 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nANgs-0007or-3s for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 03:00:49 +0000 Received: by mail-pj1-x1036.google.com with SMTP id n16-20020a17090a091000b001b46196d572so4508645pjn.5 for ; Wed, 19 Jan 2022 19:00:45 -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=PZtDtdQi2GpiE1CrLM3dz3r9IyCy43o5ayFgdn8mdC0=; b=HQWmGfz0H5+FhT1JLNl7xltMwOwy8X88K8XIS/sbKQ3U5P9kFJpZuKIv8kczHtI32q hht4/UZlmXyAXaQD1chwkqGVr2WR3YO1gMa7ljChkU+gimzdGI8wGWXoAFPm+XxFhoPo aA1j4knJZF4C7FU0cgqowNo990WGA5f/A0pZ6vv8iUFh/ni68vWVd9ZM6O2Iz8M91mP/ jX2ETfDVn9x8NHxL4J1EvEjEO3h1YSdud+IznhxmDTs+9mj0ojtuogPIHM5EJSzBCo6J wVUVHNkjth8ZSUVt6YB6q0iB5xtTd6UeSMNMKxNM+FLs0hOm2AI4l/CRm9uuZDdtMuq1 3yxA== 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=PZtDtdQi2GpiE1CrLM3dz3r9IyCy43o5ayFgdn8mdC0=; b=HqK7HUFKqN+uhPHZabfkuSoCgv7J/wFof27GoGjR6cwo1l013YEkpoVKCaN0orbQQY mY+GszQNJlyyxQZGjBOlSedB4Tae15qv6iAV+bghsZ563w8nbBniO1ethuhKuZ/nlqzl Ij/KDhDwT/NMv9EQkVUborhGx7FHqyOvzKH3nuFsc9UytDNE7emi+X7BOWTL1jNTBu+n oW+KAKqVgRoLO3LXVu6KY2DTTqLKoP9XlRkFvwu5PFRuz7I6meuV5Qc2HtHeZO1peGcX 7LbHj7qrEGbu7SxiQ7jh/Rbmn2nippAkeEgDoezXkg4psXFDv9o5Zj1tCep/PsjRS6Ot wUSA== X-Gm-Message-State: AOAM533bt51uqezbL3Ye4wHzTPjYG+Vd/5dHytIXXShXKNvmQPz8qbEW QhcQoaozhGoV625va4RnmSM= X-Google-Smtp-Source: ABdhPJzd/0UDAWp6zXT9koC+WUbyUcmUx3y+fYoswIJFxGTlN3MO1Mt6Ajw6iMAD3wm4DyZJMxqDLg== X-Received: by 2002:a17:903:2049:b0:14b:61:b19e with SMTP id q9-20020a170903204900b0014b0061b19emr2992093pla.20.1642647643685; Wed, 19 Jan 2022 19:00:43 -0800 (PST) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id j11sm988279pfu.55.2022.01.19.19.00.41 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 19 Jan 2022 19:00:42 -0800 (PST) Date: Thu, 20 Jan 2022 12:00:29 +0900 (JST) Message-Id: <20220120.120029.1092463916382268628.horikyota.ntt@gmail.com> To: bossartn@amazon.com Cc: bharath.rupireddyforpostgres@gmail.com, rjuju123@gmail.com, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org Subject: Re: Add checkpoint and redo LSN to LogCheckpointEnd log message From: Kyotaro Horiguchi In-Reply-To: References: 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, 20 Jan 2022 00:36:32 +0000, "Bossart, Nathan" wrote in > On 1/3/22, 5:52 PM, "Kyotaro Horiguchi" wrote: > > It seems to me "LSN" or just "location" is more confusing or > > mysterious than "REDO LSN" for the average user. If we want to avoid > > being technically too detailed, we would use just "start LSN=%X/%X, > > end LSN=%X/%X". And it is equivalent to "WAL range=[%X/%X, %X/%X]".. > > My first instinct was that this should stay aligned with > pg_controldata, but that would mean using "location=%X/%X, REDO > location=%X/%X," which doesn't seem terribly descriptive. IIUC the > "checkpoint location" is the LSN of the WAL record for the checkpoint, > and the "checkpoint's REDO location" is the LSN where checkpoint > creation began (i.e., what you must retain for crash recovery). My > vote is for "start=%X/%X, end=%X/%X." +1. Works for me. %X/%X itself expresses it is an LSN. regards. -- Kyotaro Horiguchi NTT Open Source Software Center