On Tue, Mar 24, 2020 at 3:40 PM Jürgen 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/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
asize equal to 1/32nd (about 3%) of shared_buffers, ... " ? My understanding was, that the parameter wal_buffers grabs
someof the existing shared_buffers for its own purpose. Is this a misinterpretation? Are shared_buffers and wal_buffers
twodifferent 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=4GB:
rhaas=# 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=# 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company