MIME-Version: 1.0
References: 
 <CADkLM=fwtE-TCU7sRnvaE74z12kOp_A+CdUwMr7aZt39pXbh6A@mail.gmail.com>
 <20200320001122.GA19602@alvherre.pgsql>
 <20200320195841.GA13662@telsasoft.com>
 <CA+TgmoYT2NnUueP5_=Z48XwVpyzciBfNxuuvYKUtLh-korZEmg@mail.gmail.com>
 <fbe9b2d9-9f89-83bd-7215-0cc646388ccc@purtz.de>
In-Reply-To: <fbe9b2d9-9f89-83bd-7215-0cc646388ccc@purtz.de>
From: Robert Haas <robertmhaas@gmail.com>
Date: Tue, 24 Mar 2020 15:58:40 -0400
Message-ID: 
 <CA+TgmoYDHKdye3JcU5pd-yRhLL+Ee5qZiCmLEfU2Zu0NmgWPuw@mail.gmail.com>
Subject: Re: Add A Glossary
To: =?UTF-8?Q?J=C3=BCrgen_Purtz?= <juergen@purtz.de>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
 Alvaro Herrera <alvherre@2ndquadrant.com>,
	Corey Huinker <corey.huinker@gmail.com>,
 Roger Harkavy <rogerharkavy@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
 Fabien COELHO <coelho@cri.ensmp.fr>,
	Michael Paquier <michael@paquier.xyz>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Mar 24, 2020 at 3:40 PM J=C3=BCrgen Purtz <juergen@purtz.de> wrote:
> 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/runtim=
e-config-wal.html : "wal_buffers (integer)    The amount of shared memory u=
sed 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 exi=
sting shared_buffers for its own purpose. Is this a misinterpretation? Are =
shared_buffers and wal_buffers two different shared memory areas?

Yes. The code adds up the shared memory requests from all of the
different subsystems and then allocates one giant chunk of shared
memory which is divided up between them. The overwhelming majority of
that memory goes into shared_buffers, but not all of it. You can use
the new pg_get_shmem_allocations() function to see how it's used. For
example, with shared_buffers=3D4GB:

rhaas=3D# select name, pg_size_pretty(size) from
pg_get_shmem_allocations() order by size desc limit 10;
         name         | pg_size_pretty
----------------------+----------------
 Buffer Blocks        | 4096 MB
 Buffer Descriptors   | 32 MB
 <anonymous>          | 32 MB
 XLOG Ctl             | 16 MB
 Buffer IO Locks      | 16 MB
 Checkpointer Data    | 12 MB
 Checkpoint BufferIds | 10 MB
 clog                 | 2067 kB
                      | 1876 kB
 subtrans             | 261 kB
(10 rows)

rhaas=3D# select count(*), pg_size_pretty(sum(size)) from
pg_get_shmem_allocations();
 count | pg_size_pretty
-------+----------------
    54 | 4219 MB
(1 row)

So, in this configuration, there whole shared memory segment is
4219MB, of which 4096MB is allocated to shared_buffers and the rest to
dozens of smaller allocations, with 1876 kB left over that might get
snapped up later by an extension that wants some shared memory.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company