Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLJzI-00022R-JM for pgsql-committers@arkaria.postgresql.org; Sat, 10 Nov 2018 03:31:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gLJzG-00023a-Tj for pgsql-committers@arkaria.postgresql.org; Sat, 10 Nov 2018 03:31:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLJzE-0001mw-Ig for pgsql-committers@lists.postgresql.org; Sat, 10 Nov 2018 03:31:06 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLJz8-0000Ru-Dj for pgsql-committers@postgresql.org; Sat, 10 Nov 2018 03:31:03 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 4FA41C00; Fri, 9 Nov 2018 22:30:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 09 Nov 2018 22:30:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=fm3; bh=0 B3ALF8Y39S2yiV/Xro9cks4E6EVaqX7ByinLF/v5Sw=; b=IFbnNNTlE8WkZ6law PU3kKOiE8airKxZc25aBrTO1TBQgr++lZjqloKc3T/k9zgxJU79Arh5QGuhzyNCi /wv0DTfZWnCRFctdRZ6qY57GQ+b3QcKVpcy0oZsia+1J/yHyeU8zbu0IoCFTplmR LO8UG5mJ0SeM0yY7R69FoQ9kQYJE+YbO6kMZkIHkLHJ9ZKuMk1RnQSHd8C2kNMZC tYBRGAr99kRlTTeawx317H3ikTIeP0HnzyC7TcOh1GQU3adP3lGptAF6OSF8wNF+ ZvPFuGk3zW7f1Y3V8Hr2/Ula2oG0RwPT4+5lpCwJa4D4w87s/84RMO72cabQuyRS 9Vc2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=0B3ALF8Y39S2yiV/Xro9cks4E6EVaqX7ByinLF/v5 Sw=; b=MwjONKAtoW5FverXpF/75Fm7Wh0uzSWqk8EsJujEW9hv2hqZ2rrrgSltu iqcFaI24Om7Ylhvo41tVTzpb1lr+kHR5dKmnZ53GwqnpnpBUaFZw84nRLau8GHGD OEbvFLST690kvz5WnZlSTAOO3/kEvL6c5KoWb2P/bzgQ3Z96HE7RKee4APl71Pdr NzS6hXGxGNK01bwheLERDhDr5+NgfcdRVyF56a/YisJovG+1WM8aywh3LhrUaMY/ 5uHOF8qHkspZmpfqayhivyHR7zalTRn1HWNJoEAqB74S5/74K22ljLaRINWl3INX YGVff7FW9695/jBCfDrHc9kMYDdQw== X-ME-Sender: X-ME-Proxy: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 271BAE4443; Fri, 9 Nov 2018 22:30:54 -0500 (EST) Date: Fri, 9 Nov 2018 19:30:52 -0800 From: Andres Freund To: David Steele Cc: pgsql-committers@postgresql.org Subject: Re: pgsql: Make WAL segment size configurable at initdb time. Message-ID: <20181110033052.xmmozibdapwvenkx@alap3.anarazel.de> References: <68ea97d6-2ed9-f339-e57d-ab3a33caf3b1@pgmasters.net> <20181005165447.zyzglieznybyi7wu@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-11-09 21:45:18 -0500, David Steele wrote: > On 10/5/18 1:03 PM, David Steele wrote: > > Hi Andres, > > > > On 10/5/18 5:54 PM, Andres Freund wrote: > >> On 2018-09-20 11:48:08 -0400, David Steele wrote: > >> > >>> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml > >>> index e1073ac6d3..3bfd172441 100644 > >>> --- a/doc/src/sgml/config.sgml > >>> +++ b/doc/src/sgml/config.sgml > >>> @@ -8440,10 +8440,8 @@ dynamic_library_path = > >>> 'C:\tools\postgresql;H:\my_project\lib;$libdir' > >>>         > >>>         > >>>          > >>> -        Reports the number of blocks (pages) in a WAL segment file. > >>> -        The total size of a WAL segment file in bytes is equal to > >>> -        wal_segment_size multiplied by > >>> wal_block_size; > >>> -        by default this is 16MB.  See >>> linkend="wal-configuration"/> for > >>> +        Reports the size of write ahead log segments. > >>> +        The default value is 16MB. See >>> linkend="wal-configuration"/> for > >>>           more information. > >>>          > >>>         > >> > >> Why is this actually more correct? You mean because we have a conversion > >> that does the mb conversion at display time? > > > > In pre-11 versions of Postgres, you get this: > > > > postgres=# select setting, unit from pg_settings where name = > > 'wal_segment_size'; > >  setting | unit > > ---------+------ > >  2048    | 8kB > > > > But in v11 you get this: > > > > select setting, unit from pg_settings where name = 'wal_segment_size'; > >  setting  | unit > > ----------+------ > >  16777216 | B > > > > So, while the WAL segment size used to be expressed in terms of 8K pages > > it is now expressed in terms of absolute bytes.  This seemed to me to be > > a very deliberate change in the original commit so I guessed it was done > > for clarity, but that the docs didn't get the message. > > Thoughts on this? > > I know it's minor in the grand scheme of things but it caused me some > confusion when I was updating pgBackRest for v11 and I imagine it might > do the same for others. Sorry for forgetting this, pushed. I kinda wonder whether we should move a few GUCs out of the section. Or adapt its description. Because a significant portion of its contents don't accurately seem to be described by The following parameters are read-only, and are determined when PostgreSQL is compiled or when it is installed. right? Greetings, Andres Freund