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

Hi

2026年7月23日(木) 0:07 Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>:
>
> Hi,
(...)
>
> Two things I'm unsure about and would welcome opinions on: whether a byte
> count defaulting to min_wal_size is the right interface or a plain segment
> count would be more honest;

A plain segment count feels like the more intuitive value to provide, especially
as the function returns the number of segments created. OTOH min/max_wal_size
etc. are all specified by size, so maybe that's more consistent.

Regarding min_wal_size, if there is already more than that amount of WAL
present, the function is basically just adding an arbitrary number of
WAL segments.
Maybe the function could, if no value is provided, just create segments until
min_wal_size is reached?

> and whether there should be a cap, since nothing
> currently stops a request large enough to fill the disk.

Could max_wal_size be a reasonable default cap or soft upper limit?

Minor code nitpick:

-#define CATALOG_VERSION_NO 202607201
+#define CATALOG_VERSION_NO 202607220

I don't think the catalog version bump is needed in patches,
it's up to the committer to set the appropriate value at commit time.

Regards

Ian Barwick