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 1mpgUS-0006Yn-NH for pgsql-docs@arkaria.postgresql.org; Wed, 24 Nov 2021 00:50:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mpgUQ-00083b-9V for pgsql-docs@arkaria.postgresql.org; Wed, 24 Nov 2021 00:50:22 +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 1mpgUQ-00083S-0Q for pgsql-docs@lists.postgresql.org; Wed, 24 Nov 2021 00:50:22 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mpgUN-0008Ta-D8 for pgsql-docs@lists.postgresql.org; Wed, 24 Nov 2021 00:50:21 +0000 Received: by mail-pl1-x630.google.com with SMTP id y8so479239plg.1 for ; Tue, 23 Nov 2021 16:50:18 -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=0sPaLeCJ/k989okAerjEaYCbkohS7teIMvSAKo+UxIg=; b=OI7gjj2ROs5Dc7YWtu2GrdmFIoS1VYqIzIODLsQ22dI5+63r38ajjoR7fTgmLpq4XY LroPsb0EKoAS5WI3Q7MsB39iAJFwn914ad3Lo4WwlKMZOuoJW8iWow2dgEm7aM75BwjG wcWpuwoLr/bzXxwFh4jWcqE0CG/I6wRmTwJMdPXXGW/3a/ix53M1LarLq4lgjeIL+VwL NiEW+ZsxLaJ9AaPqKQsy14iZJ703fhwjZIXO/vclenakHFRmP/JFBrJJR4MnLMHNxdwU XA42DMyvYc4p4oD8b5SYzPPM+qI7HVrez02ujl/A7ohO5Pyv/xdwB8DRIGMwixo2WDYz T9rA== 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=0sPaLeCJ/k989okAerjEaYCbkohS7teIMvSAKo+UxIg=; b=Ft+ZtKUAV/+pz67AUDoqCfEhp3objsSGtLPVRiL+fNWprmVPe3WrNsb1tTJKO2hWxp +QaTlFGHI3xajPv0VUj+e9/dBtvc5neGbAhzbE4VaB94w2HRTmYZl68ruQ861JO2arBI N4W7lDfHyaCedyscFX/SZT+Av0aXOCOqJ6U7d/ZFn3zFPSawtpPA3X4dLLmWZiNkM/Gx hZu43/Zr/WpK2snsvggxY77nCBZjOiPyDF2lv/nvk6EWH2xpQvrzpc0xyp5F1jz5Hhvn FaY3wAFBYYIWy+6Lr+8tCNkbQurQwSbl/7mARPB+uNW8Wk63QFpx25M6FBG6JZImx9JC 40fw== X-Gm-Message-State: AOAM532qiVOjG0lg7p8A2nn24FadaQiReL3jPELVqFAQ1dc5vJngz7Dc CTx1rnFaU5Q5QFSjXx9dILs= X-Google-Smtp-Source: ABdhPJwpKgJ90nJlZjdcEYmG9Lzs8U6hkpwUZYiCO5SJ9kO+m0Dl6BDFCsJCkcGpflJ9AQChjr3ZmQ== X-Received: by 2002:a17:90b:3e81:: with SMTP id rj1mr2521475pjb.111.1637715016909; Tue, 23 Nov 2021 16:50:16 -0800 (PST) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id e23sm9863143pgg.68.2021.11.23.16.50.14 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 23 Nov 2021 16:50:15 -0800 (PST) Date: Wed, 24 Nov 2021 09:50:13 +0900 (JST) Message-Id: <20211124.095013.1928208020303363469.horikyota.ntt@gmail.com> To: alvherre@alvh.no-ip.org Cc: b1000101@pm.me, pgsql-docs@lists.postgresql.org Subject: Re: max_slot_wal_keep_size unit is not specified From: Kyotaro Horiguchi In-Reply-To: <202111231421.zybfdpc5pyln@alvherre.pgsql> References: <163760291192.26193.10801700492025355788@wrigleys.postgresql.org> <202111231421.zybfdpc5pyln@alvherre.pgsql> 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 Tue, 23 Nov 2021 11:21:05 -0300, Alvaro Herrera wrote in > On 2021-Nov-22, PG Doc comments form wrote: > > > The unit (I assume it's MB) of max_slot_wal_keep_size is not explicitly > > specified in the docs. If it's intentional then please, disregards, but I've > > not been able to deduct that from this page alone. Thanks! > > Well, that's embarrasing. I'll see about fixing it. (facepalm..) > It is a size-based unit. You would typically specify some unit (say, > MB) together with the number; internally, because the way this works is > in terms of whole files, it is rounded down to an integer number of WAL > segments. If you don't specify a unit, it is taken to be a number of > megabytes. > > I wonder why did we make it round down rather than up. Does this mean > that if you have max_slot_wal_keep_size=8MB and wal segments of 16 MB, > the slot gets invalidated with more than zero reserved segments? That rounding behavior is the way we are generally doing on similar variables. It is based on the behavior of ConvertToXSegs(). So max_wal_size for example is rounded-up the same way. regards. -- Kyotaro Horiguchi NTT Open Source Software Center