[db] Add context propagation for PostgreSQL via SET application_name

[mhennoch]

Add context propagation for PostgreSQL via SET application_name

Part of #2162

Adds SET application_name as a context propagation mechanism for PostgreSQL, following the pattern established for SQL Server (SET CONTEXT_INFO) and Oracle (V$SESSION.ACTION).

Why SET application_name?
PostgreSQL instrumentation already supports SQL Commenter, but it has limitations:

• Prepared statements — SQL Commenter cannot be used with named/prepared queries, as the comment is baked into the statement text and every subsequent execution carries stale trace context.
• Stored procedures — SQL comments on the outer CALL statement are not visible to queries executed inside the procedure body.

SET application_name operates at the session level and avoids all of these issues. The value is visible in pg_stat_activity and the OpenTelemetry Collector PostgreSQL receiver already parses it to extract trace context from query samples.

Note on application_name

There is ongoing discussion about whether application_name is the ideal long-term mechanism — a protocol-level approach would be better but doesn't exist today. An imperfect convention behind an opt-in flag is still useful: it unblocks users now and can help motivate database-native solutions over time.

Existing implementations

• Java (PostgreSQL): splunk-otel-java#2540
• Datadog: https://github.com/DataDog/dd-trace-java/blob/8db72c0988adb1010c1f2d6b028b93b10cd10ff2/dd-java-agent/instrumentation/jdbc/src/main/java/datadog/trace/instrumentation/jdbc/JDBCDecorator.java#L372

[XSAM]

👍

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.

[pellared]

This is a good step forward. Even if we later decide that application_name is not the ideal long-term propagation mechanism, having a documented convention now is useful: it gives instrumentation authors something interoperable to implement, helps users immediately, and can also inform a future redesign if we later standardize a better carrier or protocol-level approach.

[pellared]

This never says to restore or clear the prior value afterwards. PostgreSQL SET is session-scoped, and application_name is commonly set at connection time and surfaced in pg_stat_activity/logs, so on pooled connections this would overwrite the caller’s configured app name and can leak stale trace IDs into later operations. I think the spec needs either explicit restore/reset semantics or a clear incompatibility warning.

[pellared]

I think we should make an explicit design choice here:

1. Either this convention is W3C Trace Context-specific, in which case the spec should say so directly and normatively define application_name as carrying only traceparent.
2. Or we want this to support arbitrary propagators, in which case we should define application_name as a context propagation carrier, similar to the env-carriers spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/context/env-carriers.md.

Right now the text sits in between those two models. It says “for example, when using W3C Trace Context” but does not actually define carrier semantics for non-W3C propagators.

If we choose the generic route, the carrier should be format-agnostic and treat the value as an opaque string, while the propagator remains responsible for key selection, encoding, validation, and any truncation behavior. We would also need to specify how a multi-field propagator maps into a single application_name string with a tight length limit.

My preference is to decide this explicitly in the spec rather than leave it implicit in instrumentation behavior. Given application_name size is limited. I think this should be always the one representation; the same as for traceparent or some other custom one. We may consider adding some _TP_ (which would stand for traceparent) prefix following what Datadog implementation does.

[pellared]

@open-telemetry/semconv-db-approvers, can you take a look as well?