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

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.

Regards,
Ayush