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

Hi,

On Thu, 23 Jul 2026 at 11:14, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

> Hi,
>
> On Wed, 22 Jul 2026 at 21:30, Ian Lawrence Barwick <barwick(at)gmail(dot)com>
> wrote:
>
>> 2026年7月23日(木) 0:07 Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>:
>> >
>> > Hi,
>> (...)
>> >
>> > Two things I'm unsure about and would welcome opinions on: whether a
>> byte
>> > count defaulting to min_wal_size is the right interface or a plain
>> segment
>> > count would be more honest;
>>
>> A plain segment count feels like the more intuitive value to provide,
>> especially
>> as the function returns the number of segments created. OTOH
>> min/max_wal_size
>> etc. are all specified by size, so maybe that's more consistent.
>>
>
> Thanks for the review!
>
> I went back and forth too. I'd keep bytes for now, for consistency with
> min/max_wal_size and so it composes with pg_size_bytes('1GB'), but I'm
> happy to
> switch if the count reads better to people.
>
>
>> Regarding min_wal_size, if there is already more than that amount of WAL
>> present, the function is basically just adding an arbitrary number of
>> WAL segments.
>> Maybe the function could, if no value is provided, just create segments
>> until
>> min_wal_size is reached?
>>
>
> That's what it already does, just undocumented: existing segments are
> skipped,
> so the default only creates the missing ones in the min_wal_size window
> ahead
> of the insertion point (0 if they're already there). I'll make the docs
> say so.
>
>
>> > and whether there should be a cap, since nothing
>> > currently stops a request large enough to fill the disk.
>>
>> Could max_wal_size be a reasonable default cap or soft upper limit?
>>
>
> Possibly. I left it uncapped for now since it's a superuser-only explicit
> action, but max_wal_size is a sensible ceiling if we want one. Happy to
> add a
> soft clamp if there's appetite for it.
>
>
>> Minor code nitpick:
>>
>> -#define CATALOG_VERSION_NO 202607201
>> +#define CATALOG_VERSION_NO 202607220
>>
>> I don't think the catalog version bump is needed in patches,
>> it's up to the committer to set the appropriate value at commit time.
>>
>
> Agreed, I'll drop it in the next rebase / v2.
>

Rebased with updated doc and reverted catalog_version_no.

Regards,
Ayush