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-04 15:10:53
Message-ID: CAJTYsWVDbNjzyD6o_HR6y1GNevOG4iBC4tKDkqJoL07_md52qg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, 4 Aug 2026 at 13:55, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

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

v5 attached.

It does [1] instead of silently creating segments.

Nothing gets created when it errors out, and the NOTICE is gone.

I ended up comparing after rounding up to whole segments rather than on the
byte value directly. Otherwise asking for exactly max_wal_size still sneaks
a
segment past it when max_wal_size isn't a multiple of the segment size.

The no-argument form still uses min_wal_size and skips the check, since
that is
what the server keeps anyway.

Regards,
Ayush

[1] ERROR: WAL preallocation request exceeds "max_wal_size"
DETAIL: The request needs 64 WAL segments, but "max_wal_size" allows 8.
HINT: Call pg_wal_preallocate() with "force" set to true to bypass this
limit.

Attachment Content-Type Size
v5-0001-pg_wal_preallocate.patch application/octet-stream 19.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-08-04 15:11:40 Re: doc: clarify wal_sender_shutdown_timeout behavior for small values
Previous Message Stepan Neretin 2026-08-04 14:47:37 Re: Fix archive restore race that could unlink WAL before rename