Skip to content

Add terminationGracePeriodSeconds support for PgBouncer in Helm chart - #71237

Open
antruigon wants to merge 2 commits into
apache:mainfrom
antruigon:add-pgbouncer-termination-grace-period
Open

Add terminationGracePeriodSeconds support for PgBouncer in Helm chart#71237
antruigon wants to merge 2 commits into
apache:mainfrom
antruigon:add-pgbouncer-termination-grace-period

Conversation

@antruigon

Copy link
Copy Markdown

What

Adds pgbouncer.terminationGracePeriodSeconds to the Helm chart, rendered on the PgBouncer Deployment's pod spec. Defaults to 120 to match the drain window of the chart's default preStop hook.

Why

The chart ships a default PgBouncer preStop hook that drains client connections for up to 120 seconds:

containerLifecycleHooks:
  preStop:
    exec:
      # Allow existing queries clients to complete within 120 seconds
      command: ["/bin/sh", "-c", "killall -INT pgbouncer && sleep 120"]

…but the Deployment never sets terminationGracePeriodSeconds, so the Kubernetes default of 30s SIGKILLs the pod mid-drain. On any node drain or eviction (cluster upgrades, autoscaler scale-down, AMI rolls) in-flight client connections are cut instead of drained — workers see psycopg2.OperationalError: server closed the connection unexpectedly, and tasks that were mid-query fail. We hit this in production during a routine EKS node-group AMI roll: one evicted PgBouncer replica cut ~880 in-flight connections and failed 21 zero-retry DAG runs.

Every other long-running component in the chart already exposes this knob (scheduler, workers.celery, triggerer, dagProcessor, statsd, redis, otelCollector); PgBouncer was the only one missing it, and it is arguably the component that needs it most since it holds everyone's DB connections.

Default choice

120, matching the shipped preStop. Note this is an upper bound, not a fixed wait: PgBouncer receives SIGINT immediately, stops accepting new connections, and exits as soon as the last client connection is released — so pods still terminate quickly under low load. Users who prefer the old behaviour can set it back to 30.

Changes

  • chart/values.yaml — new pgbouncer.terminationGracePeriodSeconds: 120 next to the preStop hook it pairs with
  • chart/values.schema.json — schema entry (integer, default 120, Kubernetes docs section)
  • chart/templates/pgbouncer/pgbouncer-deployment.yaml — render the field on the pod spec
  • chart/tests/helm_tests/other/test_pgbouncer.py — parametrized test for default + override (mirrors test_statsd.py)

All 86 tests in test_pgbouncer.py + test_pdb_pgbouncer.py pass locally.

The chart ships a default PgBouncer preStop hook that drains client
connections for up to 120 seconds (killall -INT pgbouncer && sleep 120),
but the Deployment never sets terminationGracePeriodSeconds, so the
Kubernetes default of 30s SIGKILLs the pod mid-drain on any node drain
or eviction, cutting in-flight client connections.

Every other long-running component in the chart (scheduler, workers,
triggerer, dag-processor, statsd, redis, otel-collector) already exposes
this value; PgBouncer was the only one missing it.

Defaults to 120 to match the drain window of the default preStop hook.
Since PgBouncer exits as soon as the last client connection is released,
the full 120s is an upper bound, not a fixed wait.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@boring-cyborg

boring-cyborg Bot commented Aug 6, 2026

Copy link
Copy Markdown

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

  • Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
  • In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
  • Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
  • Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
  • Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
  • Be sure to read the Airflow Coding style.
  • Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
    Apache Airflow is a community-driven project and together we are making it better 🚀.
    In case of doubts contact the developers at:
    Mailing List: dev@airflow.apache.org
    Slack: https://s.apache.org/airflow-slack

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:helm-chart Airflow Helm Chart

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant