Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jGpPn-0006rZ-EB for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2020 19:40:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jGpPm-0001FV-0n for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2020 19:40:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jGpPl-0001Dn-Ki for pgsql-hackers@lists.postgresql.org; Tue, 24 Mar 2020 19:40:41 +0000 Received: from mout.kundenserver.de ([212.227.126.135]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jGpPe-0007FU-NI for pgsql-hackers@postgresql.org; Tue, 24 Mar 2020 19:40:40 +0000 Received: from [192.168.178.43] ([77.181.21.121]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MxDgm-1jRvHZ0aHg-00xemj; Tue, 24 Mar 2020 20:40:21 +0100 Subject: Re: Add A Glossary To: Robert Haas Cc: Justin Pryzby , Alvaro Herrera , Corey Huinker , Roger Harkavy , "pgsql-hackers@postgresql.org" , Fabien COELHO , Michael Paquier References: <20200320001122.GA19602@alvherre.pgsql> <20200320195841.GA13662@telsasoft.com> From: =?UTF-8?Q?J=c3=bcrgen_Purtz?= Message-ID: Date: Tue, 24 Mar 2020 20:40:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D3F7502C062025418154D528" Content-Language: en-US X-Provags-ID: V03:K1:R+hyV9nQsxMMYO+rd2yMIsRoqQbQ4v4K6Z51hH1G5YuGVxs0d/3 wlj+e+heXhGqw5qphFv9mFmLl+GU3E9cFZD8Aa0MXnW5wDhOEo9MPuGlie+B5wb6k5u6IUf tkLWUAZUdEjl8dIDA5UWr/Q1BiVvS50U4qtBpurWHaT04hLiXZmRFxkl4q0eqwmQLCDMuVR JSxdY8gbipnlOGBZ3UVyA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:cBu2LpZXgsg=:zwjpxdOIIIgnPBkh7Kpl50 D3Y7RX/aYg5c3dmc/zZxFo79VGhfDDVyAL8vrqMPdJxgk8Ky4r0nlGdUKX71zHSHS71cx9bVg iWmiGFhrqJ6nyLHjp30LoKUITNCxozCC3SHaY0tqJTg3KyvmXiBMCcmtWoKC2TAjlUFNkrHqk b4xCLtCt6W4sAYE85/X6S79GoszeZRiFIytHm7aKDvpZ08nSlq7igzZFyDtJ1GzrE42qyNI6N DvN4zslLCNOIS8L5hQYeUH80nYYxw2xmjl+Utg5e+TxEVB0VHIgnIV89twQcxGHAKc75Dz68U t1tm/8GpHuemjuGDcdPOhWWW1gwzUtZxyAuJUvM27GEgsUvAGgx7QHrUldqT85By1jo0N1RSe 3n9qHvMB2Mn0shdN7cTCSyLln5Fr+dSNHIXy0o5lbLsZJJYZk2+olZC0DD9zdVZbR0uzqysnr iAV2EApHbzlM1ri3OdkPLTo9HTSZhxoDFdF3kjMV8WrMK6xjjfl+dCseZxpQSeXp6M8VDaU0U 2k0TRBeCh/3NACyL37lDeRPhcfTp+N+91Dp8p0rmQZrptbPzURu+mi699BBZCR7z3z+cDYHcC Jaza8i+fHH37gz5LF0S3vq9jHrLH2imAf4kdi2gdViWxDvP1U33KOiz50S4+Mu8yMFVPn4JER kj/7frVyHNByDHEt2+Dr3vD/u7qKgJYCwmznSrlBcb7Gdd3arDucFTa4uPUVqUFKzv+Xh6Jku Hzt4swLmFJj734LXo/zz9566vjYtG2gIvy2QwRRHvCDzBl3Q22AEl5wsgGYl77wducVNKls/O sFxf06lN5H9UW2OwOq3KA/cptRGbbOrbWWnodjjwKRCAZaWfdlhBmqLCMlMJEqTJJPTSyCp List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------D3F7502C062025418154D528 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 24.03.20 19:46, Robert Haas wrote: >> Do we use shared_buffers for WAL ? > No. What's about the explanation in https://www.postgresql.org/docs/12/runtime-config-wal.html : "wal_buffers (integer)    The amount of shared memory used for WAL data that has not yet been written to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%) of shared_buffers, ... " ? My understanding was, that the parameter wal_buffers grabs some of the existing shared_buffers for its own purpose. Is this a misinterpretation? Are shared_buffers and wal_buffers two different shared memory areas? Kind regards, Jürgen --------------D3F7502C062025418154D528 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 24.03.20 19:46, Robert Haas wrote:
Do we use shared_buffers for WAL ?
No.

What's about the explanation in https://www.postgresql.org/docs/12/runtime-config-wal.html : "wal_buffers (integer)    The amount of shared memory used for WAL data that has not yet been written to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%) of shared_buffers, ... " ? My understanding was, that the parameter wal_buffers grabs some of the existing shared_buffers for its own purpose. Is this a misinterpretation? Are shared_buffers and wal_buffers two different shared memory areas?

Kind regards, Jürgen


--------------D3F7502C062025418154D528--