From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Luca Ferrari <fluca1978(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_wal lifecycle |
Date: | 2021-07-13 13:43:12 |
Message-ID: | 5cd3241a-f1d3-9881-e3a2-823075d6d6c3@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 13.07.21 09:07, Luca Ferrari wrote:
> I'd like to see if I get it right about pg_wal: it grows up to pretty
> much max_wal_size, at which point a checkpoint is triggered.
> If the server triggers a timed checkpoint before the pg_wal is at
> max_wal_size, the system recycles the wals thus keeping the pg_wal
> size lower than max_wal_size.
> Is this correct? In particular, what is in simple words, the
> discrimination between recycling a segment and creating a new one?
Recycling in this context just means that instead of creating a new WAL
file for new WAL traffic, it reuses an old file. So if you have WAL
files 5, 6, 7, 8, 9, and you know that you don't need 5 and 6 anymore,
when you need to start WAL file 10, instead of creating a new file "10",
the system just renames "5" to "10" and starts overwriting what was in
there. This is just an optimization to use the file system better; it
doesn't affect the logical principles of what is going on.
From | Date | Subject | |
---|---|---|---|
Next Message | David Gauthier | 2021-07-13 14:00:34 | Need to check each element of an array satisfies a foreign key constraint |
Previous Message | Peter Eisentraut | 2021-07-13 13:37:04 | Re: libicu global support |