Azure Database for PostgreSQL Flexible Server: platform-managed components, FATAL/PANIC logging, and the azuresu role

Azure Database for PostgreSQL Flexible Server documents customer-configurable PostgreSQL logs, Query Store, and Microsoft’s control-plane superuser role, but it does not publicly document the complete telemetry schema, internal retention, or every operation performed by the named platform components.

1. Platform-managed components

The publicly documented scope differs by component:

• pgaadauth supports Microsoft Entra authentication, including functions used to create Entra principals. Its internal implementation, telemetry, storage, and retention are not publicly specified.^1^
• pgms_stats is associated with Query Store plumbing. For example, pgms_stats.is_enabled_fs is documented as an internal-use-only, read-only feature override.^2^
• pg_availability does not have a current public product page describing its contract, collected fields, storage, or retention.
• The purpose and data-handling contract of a component named azure are likewise not described by the supplied public product documentation.
• These internal components should not be treated as customer-managed extensions merely because they appear in catalogs or preload lists. The documented customer-loadable libraries are managed through shared_preload_libraries; internal components are not necessarily exposed through that interface.^3^

A separate, documented feature that does capture query text is Query Store. It is opt-in, stores query history and runtime statistics in the azure_sys database, and can capture top-level or nested queries depending on pg_qs.query_capture_mode.^4^

For Query Store:

• none stops capturing new queries.
• top captures top-level client queries.
• all also captures nested statements.
• pg_qs.retention_period_in_days controls retention; the documented default is seven days.
• Old statistics and unreferenced query texts/plans are deleted after that period.^5^
• query_store.qs_reset removes the information Query Store has recorded, including captured query text.^4^

There is no public documentation establishing that azure, pgaadauth, pgms_stats, or pg_availability independently record bind-parameter values or PostgreSQL error CONTEXT. That would require confirmation from Microsoft Support or the product group.

2. FATAL/PANIC and SQL text

For standard PostgreSQL logging, log_min_error_statement causes the statement producing an error at or above the configured severity to be logged. Its documented default is error; therefore, FATAL and PANIC are included at that setting because each level includes those following it.^6^

log_error_verbosity controls how much detail is written for messages that are logged. Supported values are terse, default, and verbose.^7^ These settings control PostgreSQL’s standard log output, but the documentation says that only most, not all, PostgreSQL logging parameters are customer-configurable.^8^

Consequently:

• SQL text may appear through log_min_error_statement, log_statement, duration logging, pgaudit, or Query Store.
• Error details may appear in server-log fields such as Message and Detail.
• Logs can contain sensitive information, including credentials; Microsoft explicitly warns about this.^8^
• pgaudit normally logs statements. Microsoft recommends pgaudit.log=ROLE rather than log_statement=DDL/ALL for role password operations because PostgreSQL statement logging can expose passwords, whereas that pgAudit class redacts them.^9^

The PostgreSQL settings do not govern Query Store capture. No public document states whether they govern every Microsoft-internal diagnostic path.

Log destinations, access, and retention

1. Downloadable server logs: Enable or disable capture under Flexible server → Monitoring → Server logs. Retention is customer-configurable from one through seven days; the default is three days.^10^
2. Azure Monitor destinations: Diagnostic settings can route categories including PostgreSQL server logs and Query Store SQL text to Log Analytics, Storage, or Event Hubs.^11^
3. Access: Roles providing server-log read access—including Reader, Monitoring Reader, Log Analytics Reader, or equivalent custom roles—can download logs.^8^
4. Retention: Log Analytics retention is set at workspace or table level. Storage and Event Hubs use their destination-specific retention/lifecycle controls.^12^
5. Deletion: Stopping a diagnostic setting prevents new ingestion but does not immediately delete existing records. Azure tables remain until their retention period expires; targeted deletion/purge is restricted, destructive, and intended primarily for personal-data requirements.^13^

3. azuresu and Microsoft access

azuresu is the Microsoft-only PostgreSQL superuser role used for control-plane operations. Customer administrators are members of azure_pg_admin, not azuresu, and cannot grant themselves membership.^14^

Public documentation does not enumerate:

• Every control-plane operation executed as azuresu.
• Whether each such operation produces a customer-visible PostgreSQL audit event.
• The schema or retention of Microsoft-internal operational records.
• A customer-accessible audit trail mapping every azuresu session to an individual Microsoft operator.

At the Azure-wide level, Microsoft personnel have no default access to customer data. Required access uses least privilege, just-in-time access, MFA, secure consoles, and audited access requests.^15^

Customer-visible audit surfaces have narrower scopes:

• Azure Activity Log records control-plane resource operations, normally not database reads, and retains them for 90 days unless exported.^16^
• PgAudit records configured database activity, but the documentation does not guarantee that every Microsoft platform action appears there.
• Customer Lockbox can provide approval and audit records when eligible Microsoft support access requires customer-data access. The current service list includes Azure Database for PostgreSQL, but eligibility for the specific subscription and Flexible Server scenario should be confirmed before relying on it; emergency “break-glass” exclusions apply.^17^

For compliance evidence covering undocumented component behavior, internal diagnostic retention, or individual azuresu operations, open an Azure support request and request a written product-group statement tied to the server’s region, PostgreSQL version, and support/Lockbox configuration.

References

1. Connect with managed identity in Azure Database for PostgreSQL flexible ...
2. Query Store (postgresql-15)
3. Load libraries in Azure Database for PostgreSQL flexible server
4. Query store in Azure Database for PostgreSQL flexible server
5. Best practices for query store in Azure Database for PostgreSQL flexible server
6. Reporting and Logging / When to Log (postgresql-18)
7. Reporting and Logging / What to Log (postgresql-18)
8. Logs in Azure Database for PostgreSQL flexible server
9. Audit logging in Azure Database for PostgreSQL flexible server
10. Download PostgreSQL and upgrade logs in Azure Database for PostgreSQL flexible server
11. Configure and access logs in Azure Database for PostgreSQL
12. Azure Monitor Logs cost calculations and options
13. Manage personal data in Azure Monitor Logs
14. Access management in Azure Database for PostgreSQL flexible server
15. Azure customer data protection
16. Activity log in Azure Monitor
17. Customer Lockbox for Microsoft Azure