Re: Add a pg_wal_preallocate() SQL function to eagerly create future WAL segments

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Cc: solai v <solai(dot)cdac(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>
Subject: Re: Add a pg_wal_preallocate() SQL function to eagerly create future WAL segments
Date: 2026-08-03 14:24:32
Message-ID: CAJTYsWUGt3mZFfAVLOgadvdY72M6e2cOPkg+C9Xe4o81kBFHHQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, 3 Aug 2026 at 17:30, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

> Hi,
>
> On Mon, 3 Aug 2026 at 16:38, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> wrote:
>
>> Patch LGTM, it works as intended. My only concern is the unbounded max
>> limit; which can cause problems. I think 'max_wal_size' is a
>> reasonable limit. Perhaps we can add a 'force' boolean option to
>> function, then it can bypass the 'max_wal_size' limit; what do you
>> think?
>>
>
> Thanks for the review! I like the idea you suggested.
>
> Let me try implementing it that way.
>

v4 attached.

By default the request is now limited to the whole segments that fit within
max_wal_size, and force => true bypasses that when you really do want a
bigger
warm-up. A NOTICE is issued only when an explicit request is reduced; a
plain
no-argument call stays quiet.

Regards,
Ayush

Attachment Content-Type Size
v4-0001-pg_wal_preallocate.patch application/octet-stream 19.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Bertrand Drouvot 2026-08-03 14:20:16 Redesign per-backend statistics