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