From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Don't keep closed WAL segment in page cache after replay |
Date: | 2025-07-02 17:12:37 |
Message-ID: | 22c1e824-c378-4de8-9977-b1fca87d92b7@oss.nttdata.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025/07/02 22:24, Fujii Masao wrote:
>
>
> On 2025/07/02 19:10, Anthonin Bonnefoy wrote:
>> Hi,
>>
>> I've been looking at page cache usage as some of our replicas were
>> under memory pressure (no inactive pages available) which led to WAL
>> replay lag as the recovery process had to read from disk. One thing
>> I've noticed was that the last WAL files are in the pagecache even
>> after having been replayed.
>>
>> This can be checked with vmtouch:
>> vmtouch pg_wal/*
>> Files: 141
>> Directories: 2
>> Resident Pages: 290816/290816 1G/1G 100%
>>
>> And page-types shows a replayed WAL file in the active LRU:
>> page-types -Cl -f 000000010000001B00000076
>> page-count MB long-symbolic-flags
>> 4096 16 referenced,uptodate,lru,active
>>
>> From my understanding, once replayed on a replica, WAL segment files
>> won't be re-read. So keeping it in the pagecache seems like an
>> unnecessary strain on the memory (more so that they appear to be in
>> the active LRU).
>
> WAL files that have already been replayed can still be read again
> for WAL archiving (if archive_mode = always) or for replication
> (if the standby is acting as a streaming replication sender or
> a logical replication publisher). No?
Also, the WAL summarizer might read those WAL files as well.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2025-07-02 17:20:22 | Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly |
Previous Message | Masahiko Sawada | 2025-07-02 17:02:00 | Re: Inconsistent LSN format in pg_waldump output |