Skip to content

fix: reduce startupProbe periodSeconds without losing failure tolerance#992

Merged
mnencia merged 2 commits into
mainfrom
dev/startup-probe-period
Jul 9, 2026
Merged

fix: reduce startupProbe periodSeconds without losing failure tolerance#992
mnencia merged 2 commits into
mainfrom
dev/startup-probe-period

Conversation

@NiccoloFei

@NiccoloFei NiccoloFei commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

The startup probe for the injected plugin-barman-cloud sidecar previously left periodSeconds unset, so the API server defaulted it to 10s. Because the sidecar is a native init container that gates the main postgres container on reaching Started, this added roughly one full period to every pod's startup, even though the probe itself (a local unix-socket health check) normally succeeds in milliseconds.

periodSeconds is now 1s, so the probe reports success almost immediately in the common case. To avoid trading away failure tolerance for that faster common case, failureThreshold is raised to 30 and timeoutSeconds is lowered to 5s: a unix-socket call essentially never times out under mere load, so hitting the timeout means the sidecar is genuinely unresponsive rather than just slow, and it's fine to give that rare case more attempts before restarting the container.

Closes #991

@NiccoloFei NiccoloFei requested a review from a team as a code owner July 6, 2026 15:50
@dosubot dosubot Bot added size:XS This PR changes 0-9 lines, ignoring generated files. bug Something isn't working labels Jul 6, 2026
Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
@NiccoloFei NiccoloFei force-pushed the dev/startup-probe-period branch from 3e68e2f to 5aef349 Compare July 6, 2026 15:53
@dosubot dosubot Bot added the lgtm This PR has been approved by a maintainer label Jul 8, 2026
The 1s periodSeconds keeps the common case fast, since the probe
is a local unix socket call that normally succeeds in milliseconds.
A unix socket connection essentially never times out under mere
load, so hitting the timeout implies the sidecar is genuinely
unresponsive rather than just slow; raising failureThreshold gives
that rare case more patience before restarting the container.

Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
@mnencia mnencia changed the title fix: set a 1s default PeriodSeconds for the startupProbe fix: reduce startupProbe periodSeconds without losing failure tolerance Jul 9, 2026
@mnencia mnencia merged commit bf95543 into main Jul 9, 2026
8 checks passed
@mnencia mnencia deleted the dev/startup-probe-period branch July 9, 2026 08:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working lgtm This PR has been approved by a maintainer size:XS This PR changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Sidecar startupProbe's periodSeconds (defaults to 10s) unnecessarily slows down the startup of each pod

3 participants