[DBMON-6882] Make Postgres check teardown idempotent

[eric-weaver]

What does this PR do?

Makes PostgreSql._finalize() run at most once, guarded by a _finalized flag under the
existing _cancel_lock, and moves self.log.check = None after the final log statement.

Motivation

Two independent problems on the teardown path, both surfaced while preparing #24844 (lifting
this protocol into DatabaseCheck).

Teardown is not idempotent, and the check is already finalized more than once in practice:
run_one_check() calls cancel() and the integration_check fixture calls it again on
teardown, so every integration test closes the main connection, calls db_pool.close_all()
and re-runs async job shutdown twice. It only survives today because each individual step
happens to tolerate a second call.

Nulling log.check before the trailing debug line is a latent crash.
CheckLoggingAdapter.process re-reads self.check.check_id on every call for checks whose
check_id was never resolved, so _finalize() raises AttributeError: 'NoneType' object has no attribute 'check_id' as soon as debug logging is enabled. Verified locally against an
unmodified check.

This also unblocks #24844 from carrying transitional logic. When the base class gains the same
protocol, PostgreSql.run() reaches it through super().run(), so the inner and outer wrappers
would both finalize on an in-flight cancel. With teardown idempotent here, the base wrapper
needs no special case for integrations that have not yet migrated, and this guard moves into the
base once Postgres adopts it.

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

[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:   1 (always emitted)
Diff:            empty (no diff information)

Learn more about CI impact filtering

[datadog-official]

 

🎉 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.19%

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 85b133b654

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Review from azhou-datadog is dismissed. Related teams and files:

• database-monitoring-agent
  • postgres/datadog_checks/postgres/postgres.py

[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