From: Robert Haas <rhaas@postgresql.org>
Date: Tue, 29 Mar 2022 13:24:24 +0000 (-0400)
Subject: Explain why the startup process can't cause a shortage of sinval slots.
X-Git-Tag: REL_15_BETA1~387
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=edea649afbcedd431802a5255cd153538e43ee1d;p=thirdparty%2Fpostgresql.git

Explain why the startup process can't cause a shortage of sinval slots.

Bharath Rupireddy, reviewed by Fujii Masao and Yura Sokolov.
Lightly edited by me.

Discussion: http://postgr.es/m/CALj2ACU=3_frMkDp9UUeuZoAMjaK1y0Z_q5RFNbGvwi8NM==AA@mail.gmail.com
---

diff --git a/src/backend/storage/ipc/sinvaladt.c b/src/backend/storage/ipc/sinvaladt.c
index 68e7160b30e..2dec668bbcd 100644
--- a/src/backend/storage/ipc/sinvaladt.c
+++ b/src/backend/storage/ipc/sinvaladt.c
@@ -205,6 +205,14 @@ SInvalShmemSize(void)
 	Size		size;
 
 	size = offsetof(SISeg, procState);
+
+	/*
+	 * In Hot Standby mode, the startup process requests a procState array
+	 * slot using InitRecoveryTransactionEnvironment(). Even though MaxBackends
+	 * doesn't account for the startup process, it is guaranteed to get a
+	 * free slot. This is because the autovacuum launcher and worker processes,
+	 * which are included in MaxBackends, are not started in Hot Standby mode.
+	 */
 	size = add_size(size, mul_size(sizeof(ProcState), GetMaxBackends()));
 
 	return size;