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

Hi,

On Mon, 3 Aug 2026 at 17:24, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
> On Mon, 3 Aug 2026 at 17:30, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>> 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?
>>
>> Let me try implementing it that way.
>
> v4 attached.

Thanks!

> 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.

--
Regards,
Nazir Bilal Yavuz
Microsoft