Hi, On Thu, 23 Jul 2026 at 11:14, Ayush Tiwari <[email protected]> wrote:
> Hi, > > On Wed, 22 Jul 2026 at 21:30, Ian Lawrence Barwick <[email protected]> > wrote: > >> 2026年7月23日(木) 0:07 Ayush Tiwari <[email protected]>: >> > >> > 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. >> > > Thanks for the review! > > I went back and forth too. I'd keep bytes for now, for consistency with > min/max_wal_size and so it composes with pg_size_bytes('1GB'), but I'm > happy to > switch if the count reads better to people. > > >> 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? >> > > That's what it already does, just undocumented: existing segments are > skipped, > so the default only creates the missing ones in the min_wal_size window > ahead > of the insertion point (0 if they're already there). I'll make the docs > say so. > > >> > 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? >> > > Possibly. I left it uncapped for now since it's a superuser-only explicit > action, but max_wal_size is a sensible ceiling if we want one. Happy to > add a > soft clamp if there's appetite for it. > > >> 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. >> > > Agreed, I'll drop it in the next rebase / v2. > Rebased with updated doc and reverted catalog_version_no. Regards, Ayush
v2-0001-pg_wal_preallocate.patch
Description: Binary data
