Skip to main content
An RDS API response tells you about a database management request. It does not test a PostgreSQL connection. With Cloud Adapter, the RDS endpoint handles supported management operations while your application’s PostgreSQL driver connects to the native database endpoint. Start with the RDS PostgreSQL service profile for your directed target: operation coverage and native behavior depend on that target and install. Tuning AWS RDS PostgreSQL covers capacity and settings after you identify the failing path.

​
Find the failing path

The smallest management check is an exact read. For an install that exposes the RDS endpoint to the AWS CLI, configure its published address and the original AWS profile, then run:
Replace the address and identifier with your install’s values. A returned status or endpoint is a management observation. Reconcile it with the target’s own resource state when a create, delete or modification is still in progress. In the managed examples in the service profile, accepted changes are recorded and native work is reconciled asynchronously. A transient absence or intermediate status should prompt a bounded status read, not another create. AWS also documents DescribeDBInstances as a status and connection-information read for native RDS; see instance status and connection information.

​
If the SQL connection fails

Once the expected endpoint appears, test from the same network path as the application, with its approved PostgreSQL connection configuration. A laptop test may take a different route through private networking. Use a protected libpq service entry so the command and terminal history do not expose a password:
This SELECT changes no database state. Confirm that orders-db names the intended native endpoint, port, database, SQL identity and certificate validation policy. A connection timeout suggests checking DNS, the route from the application subnet, firewall or security-group rules, and the destination port. A TLS or certificate error belongs to the database client and trust configuration. A PostgreSQL FATAL response means the connection reached a server; check the database name, SQL user and authentication method before changing network policy. AWS’s RDS connection troubleshooting describes these distinct native failure classes. Target providers have their own network and certificate procedures; apply the procedure for the actual backend rather than copying an AWS VPC fix to another cloud. An RDS SigV4 identity authorizes management requests. It is not automatically the SQL login. Likewise, an RDS available status is not proof that the application can resolve the endpoint, validate TLS, authenticate, or run its query. Preserve the exact client error and the management observation as separate evidence.

​
Compare parameter evidence on Cloud SQL and Azure

Suppose the application still observes its old statement_timeout after a logical parameter-group change. The following are illustrative examples for two catalog mappings. Use the exact adapter version, PostgreSQL major version, group attachment, target resource identity and application SQL role. Neither investigation executes the application’s failing query.

​
Cloud SQL: reconcile a logical override with database flags

For RDS PostgreSQL → Cloud SQL for PostgreSQL, supported explicit group overrides become native database flags. Read the logical group’s user overrides with the management endpoint already configured:
The AWS command must use the installed RDS endpoint, as in the earlier example. The second command uses the target operator’s Google identity and the mapped physical instance. Inspect settings.databaseFlags; Google documents this flag inspection workflow. Then run the bounded pg_settings query in the worked case below through the application’s protected SQL service entry. Expected evidence is a three-way comparison: desired logical override, configured native flag and effective session value. If the override is absent natively, investigate attachment, supported flag mapping and recorded reconciliation failure. If the native flag is present but the session differs, inspect its source, restart requirement and application/session initialization. Do not repeatedly modify the group while the original change is still converging.

​
Azure Flexible Server: inspect its server parameter separately

For RDS PostgreSQL → Azure Database for PostgreSQL Flexible Server, the corresponding supported override becomes an Azure server parameter. Use the mapped server and resource group, not the logical RDS identifier:
The Azure parameter command is read-only. Compare its value with the same application’s pg_settings result. A restart-required setting, a session override or a parameter outside this target’s supported set needs a different resolution from a failed Google database-flag update. Preserve the Azure parameter’s units and supported values instead of copying provider-specific configuration names. In both examples, ordinary PostgreSQL traffic uses the native SQL connection and its own authentication/TLS configuration. These reads do not generate a Tensor9 report for arbitrary application SQL. A management report, when supported, explains that management request; it does not replace the native parameter and session evidence.

​
Worked case: create response lost, login times out

Suppose CreateDBInstance for orders-db lost its HTTP response. Do not repeat the create to learn whether the first request took effect. Preserve the original timestamp, request ID if received, and Explain receipt if present. Call DescribeDBInstances for orders-db with bounded backoff. If it appears, follow its status and confirm the exact native resource and endpoint in the target. If the read stays absent, record that uncertainty and inspect the target’s authorized read path before any new mutation. The status read and target observation are stronger evidence than a missing report. When the endpoint is present, try the read-only psql check from the application network. If it times out, inspect the native address, port, DNS and network rules. Do not rotate credentials in response to a timeout. If it reaches PostgreSQL and rejects authentication, compare the configured SQL principal, secret source, database name and TLS requirements. If it connects, record current_user, database and version, then move to the failing SQL or configuration setting. These are three different problems even though the original application log may say only “database unavailable.” For a parameter discrepancy, compare the logical group’s explicit overrides with a session reading such as:
Run it under the application role on the intended endpoint. A group default, unsupported target flag, restart-required change or session override can explain a difference. The logical RDS group is not a live SHOW result; see the tuning guide.

​
Keep explanation evidence private and time-bound

If the original management request carried Explain, save its x-t9-explain-id receipt and native result. Retrieve the report with T9CloudAdapter.GetExplanation at the install’s dedicated t9 endpoint, signing as service t9 with the exact original report owner’s IAM credentials and session token. A different IAM session is not the owner. The report has a fixed retention period, normally 24 hours from creation; reading it does not extend that period. A 404, incomplete revision or temporarily unavailable report does not prove that a create failed. Troubleshooting Explanations explains bounded polling and disposition handling. Export necessary evidence before owner acknowledgment or expiry, and do not replay an uncertain create to obtain another report. PostgreSQL query-plan reporting is planned and must be qualified for the exact operation and PostgreSQL-backed service implementation. It is not an RDS API for running EXPLAIN on arbitrary application SQL. If available, the complete PostgreSQL plan is private to the exact report owner and may contain relation names, predicates and literal values. Treat it as sensitive diagnostic data, and distinguish estimated plan rows from actual execution or proof of a committed mutation. Use a Support Agent to organize management, network and SQL-session evidence before deciding which operator should change the database.