Move postgres async jobs onto the DatabaseCheck job registry

[eric-weaver]

What does this PR do?

Migrates the postgres integration onto the async job registry that DatabaseCheck gained in #24442 and that shipped in datadog_checks_base 38.0.0.

• The four DBMAsyncJob instances are registered through register_async_job in a single _register_async_jobs helper that encodes the existing dbm / data_observability.enabled conditions.
• check() calls run_async_jobs(tags) instead of repeating that condition chain around four run_job_loop calls.
• cancel() calls cancel_async_jobs() in place of the local _cancel_async_jobs helper.
• _finalize() calls shutdown_async_jobs() instead of reaching into each job's private _job_loop_future to wait on it and then invoking a private _shutdown().
• Each job's _shutdown() is renamed to shutdown(), the teardown hook the base class now calls on unschedule.
• _initialize_statement_metrics re-registers after swapping in PostgresStatementMetricsV2. Both collectors use the query-metrics job name, so registration replaces the placeholder instance built in __init__ before the server version is known.

The _cancel_lock / _is_running / _cancelled deferred-finalize machinery is unchanged: cancel() still only signals, and destructive teardown still waits for an in-flight run().

Minimum datadog-checks-base is bumped to >=38.0.0 for the registry methods.

Motivation

First integration in the DBMON-6881 rollout of the job registry. Postgres was already the closest to the target shape, so it establishes the pattern that mysql, sqlserver and clickhouse will follow.

No behavior change is intended. The set of jobs that run, the order they run in, the tags they receive, and the cancel/teardown sequence all match what the removed code did.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add qa/required if this PR needs QA validation, or qa/skip-qa if it does not. Exactly one of the two is required.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

Made with Cursor

[cit-pr-commenter-54b7da]

evalya-impact-summary

evalya impact analysis

Impact analysis: RUN-ALL — every test task will run
Trigger:         empty diff (default branch, scheduled run, or shallow-clone fallback)
Test tasks:      0 (all selected)
Publish tasks:   0 (always emitted)
Diff:            empty (no diff information)

Learn more about CI impact filtering

[datadog-datadog-prod-us1]

 

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🚧 1 test that failed was ignored due to quarantine

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 94.18% (+5.77%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3db9595 | Docs | Datadog PR Page | Give us feedback!}

[dd-octo-sts]

Validation Report

All 21 validations passed.

Show details

Validation	Description	Status
agent-reqs	Verify check versions match the Agent requirements file	✅
ci	Validate CI configuration and code coverage settings	✅
codeowners	Validate every integration has a CODEOWNERS entry	✅
config	Validate default configuration files against spec.yaml	✅
dep	Verify dependency pins are consistent and Agent-compatible	✅
http	Validate integrations use the HTTP wrapper correctly	✅
imports	Validate check imports do not use deprecated modules	✅
integration-style	Validate check code style conventions	✅
jmx-metrics	Validate JMX metrics definition files and config	✅
labeler	Validate PR labeler config matches integration directories	✅
legacy-signature	Validate no integration uses the legacy Agent check signature	✅
license-headers	Validate Python files have proper license headers	✅
licenses	Validate third-party license attribution list	✅
metadata	Validate metadata.csv metric definitions	✅
models	Validate configuration data models match spec.yaml	✅
openmetrics	Validate OpenMetrics integrations disable the metric limit	✅
package	Validate Python package metadata and naming	✅
qa-label	Validate the pull request declares whether it needs QA for the next Agent release	✅
readmes	Validate README files have required sections	✅
saved-views	Validate saved view JSON file structure and fields	✅
version	Validate version consistency between package and changelog	✅

View full run