Re: Add a pg_wal_preallocate() SQL function to eagerly create future WAL segments - Mailing list pgsql-hackers

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