| From: | Joao Detomini <joao(dot)detomini(at)enterprisedb(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Limiting WAL retained for archiving, like max_slot_wal_keep_size |
| Date: | 2026-10-04 21:36:25 |
| Message-ID: | CABH8dKxScdG8E5ZhtxWVXTEJGf+mUqMWPgtYkHC8_2Lmvwbfaw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While looking at barman-wal-archive we ran into something that seems
to be missing in the server. If archiving breaks or can't keep up,
the unarchived WAL just piles up in pg_wal until the disk fills, and
max_slot_wal_keep_size doesn't help because it only covers
replication slots. We considered making the archive command drop WAL
once its queue gets too big, but then nothing tells the server, or
anyone else, that a segment was skipped on purpose, so PITR breaks
without a trace. Returning true from an archive_library for a segment
it didn't archive has the same problem, since the callback only knows
how to say "done" or "try again".
What do people think about a setting like max_slot_wal_keep_size, but
for archiving? Off by default, and once it's exceeded the server
would let the oldest unarchived segments go and record that it did,
maybe in pg_stat_archiver, so tools can notice the gap and take a new
base backup. We haven't written anything yet and wanted to ask first
whether this is something you'd want in core.
Thanks,
João Marcelo
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Joao Detomini | 2026-10-04 21:22:20 | Re: Exposing the cgroup memory limit to SQL? |