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

Hi,

On Tue, 4 Aug 2026 at 12:32, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> wrote:

>
> > 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.
>
> + if (!force)
> + {
> + int64 maxsegs = XLogMBVarToSegs(max_wal_size_mb,
> + wal_segment_size);
> +
> + if (nsegs > maxsegs)
> + {
> + /*
> + * Only report the reduction for an explicit request; the
> default
> + * (min_wal_size) is expected to fit within max_wal_size.
> + */
> + if (!PG_ARGISNULL(0))
> + ereport(NOTICE,
> + (errmsg("WAL preallocation request was reduced to
> fit "
> + "within \"max_wal_size\""),
> + errdetail("Only whole WAL segments fitting
> within "
> + "\"max_wal_size\" will be
> preallocated."),
> + errhint("Call pg_wal_preallocate() with
> \"force\" set to true "
> + "to bypass this limit.")));
> + nsegs = maxsegs;
> + }
> + }
>
> I think it is not correct to reduce the request to fit within
> max_wal_size. User wants to do something but you change the request
> without any confirmation. I think you should reject the request if
> 'bytes > max_wal_size && !force', and show a notice or error that the
> same request can be done with the force option.
>

Hmm makes sense, thanks for the input. I'll make it so.

Regards,
Ayush