On Mon, Jun 03, 2024 at 12:18:21PM -0500, Nathan Bossart wrote:
> On Tue, May 21, 2024 at 11:15:14PM +0000, Imseih (AWS), Sami wrote:
>> As far as backpatching the present inconsistencies in the docs,
>> [0] looks good to me.
>
> Committed.
Of course, as soon as I committed this, I noticed another missing reference
to max_wal_senders in the paragraph about POSIX semaphores. I plan to
commit/back-patch the attached patch within the next couple days.
--
nathan
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 883a849e6f..2f7c618886 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -884,7 +884,8 @@ psql: error: connection to server on socket
"/tmp/.s.PGSQL.5432" failed: No such
When using POSIX semaphores, the number of semaphores needed is the
same as for System V, that is one semaphore per allowed connection
(<xref linkend="guc-max-connections"/>), allowed autovacuum worker process
- (<xref linkend="guc-autovacuum-max-workers"/>) and allowed background
+ (<xref linkend="guc-autovacuum-max-workers"/>), allowed WAL sender process
+ (<xref linkend="guc-max-wal-senders"/>), and allowed background
process (<xref linkend="guc-max-worker-processes"/>).
On the platforms where this option is preferred, there is no specific
kernel limit on the number of POSIX semaphores.
