Postgres Pro
Downloads
Home   >   mailing lists

Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots. - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.
Date
Msg-id CALj2ACXZ_o7rcOb7-Rs96P0d=Ei+nvf_WZ-Meky7Vv+nQNFYjQ@mail.gmail.com
Whole thread Raw
Responses Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
Tree view 
Hi,

While working on [1], it is found that currently the ProcState array
doesn't have entries for auxiliary processes, it does have entries for
MaxBackends. But the startup process is eating up one slot from
MaxBackends. We need to increase the size of the ProcState array by 1
at least for the startup process. The startup process uses ProcState
slot via InitRecoveryTransactionEnvironment->SharedInvalBackendInit.
The procState array size is initialized to MaxBackends in
SInvalShmemSize.

The consequence of not fixing this issue is that the database may hit
the error "sorry, too many clients already" soon in
SharedInvalBackendInit.

Attaching a patch to fix this issue. Thoughts?

[1] https://www.postgresql.org/message-id/2222ab6f-46b1-d5c0-603d-8f6680739db4%40oss.nttdata.com

Regards,
Bharath Rupireddy.
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Corruption with IMMUTABLE functions in index expression.
Next
From: Bharath Rupireddy
Date:
Subject: Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()