The recent commits for this drew my attention to the comment for MAX_BACKENDS. Specifically, it says we check the value in RegisterBackgroundWorker() (which appears to have been untrue since we added max_worker_processes) and relevant GUC check hooks (which I removed last year in commit 0b1fe14). I wrote a short patch to fix this, which I intend to commit soon unless there is feedback.
-- nathan
>From 5038a5256942999bd544879d25312338686dddf2 Mon Sep 17 00:00:00 2001 From: Nathan Bossart <nat...@postgresql.org> Date: Mon, 24 Feb 2025 13:40:30 -0600 Subject: [PATCH v1 1/1] Fix comment for MAX_BACKENDS. This comment mentions that we check the configured number of backends does not exceed MAX_BACKENDS in RegisterBackgroundWorker() and relevant GUC check hooks, neither of which is true anymore. To fix, adjust this comment to state that we do the check in InitializeMaxBackends(). Oversights in commits 6bc8ef0b7f and 0b1fe1413e. --- src/include/storage/procnumber.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/include/storage/procnumber.h b/src/include/storage/procnumber.h index 75c2c7a17c0..2ddaaf0c646 100644 --- a/src/include/storage/procnumber.h +++ b/src/include/storage/procnumber.h @@ -32,8 +32,8 @@ typedef int ProcNumber; * currently realistic configurations. Even if that limitation were removed, * we still could not a) exceed 2^23-1 because inval.c stores the ProcNumber * as a 3-byte signed integer, b) INT_MAX/4 because some places compute - * 4*MaxBackends without any overflow check. This is rechecked in the - * relevant GUC check hooks and in RegisterBackgroundWorker(). + * 4*MaxBackends without any overflow check. We check that the configured + * number of backends does not exceed MAX_BACKENDS in InitializeMaxBackends(). */ #define MAX_BACKENDS_BITS 18 #define MAX_BACKENDS ((1U << MAX_BACKENDS_BITS)-1) -- 2.39.5 (Apple Git-154)
