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. Regards, Ayush
