| 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-03 14:24:32 |
| Message-ID: | CAJTYsWUGt3mZFfAVLOgadvdY72M6e2cOPkg+C9Xe4o81kBFHHQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Mon, 3 Aug 2026 at 17:30, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:
> Hi,
>
> 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?
>>
>
> Thanks for the review! I like the idea you suggested.
>
> Let me try implementing it that way.
>
v4 attached.
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.
Regards,
Ayush
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-pg_wal_preallocate.patch | application/octet-stream | 19.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Bertrand Drouvot | 2026-08-03 14:20:16 | Redesign per-backend statistics |