PG_BACKEND_PID

Return the process id of the backend serving the current session.

Syntax

PG_BACKEND_PID()

Description

## Overview Returns the process id of the backend process handling the current session. Use this value to correlate SQL activity with OS-level process telemetry (CPU, memory, open files) or to build deterministic log lines that identify the backend. ## Session context - The PID is established at session startup and does not change during the session. - Takes no arguments. - Never returns NULL. ## Behavior - Returns an INT. - Deterministic for the duration of the session. - Side effect free; no system call is made at call time. ## Compatibility - PG-compat alias for `pg_backend_pid` function.

Examples

-- Read the backend PID for the current session
SELECT PG_BACKEND_PID();

-- Include the PID in diagnostic output
SELECT PG_BACKEND_PID() AS pid, CURRENT_USER() AS user_name;

-- Correlate queries with OS-level process telemetry
SELECT PG_BACKEND_PID() AS backend_pid, INET_SERVER_ADDR() AS server_ip;

-- Persist PID with an audit row for troubleshooting
INSERT INTO ops.audit.queries (query_id, pid, started_at)
VALUES (UUID(), PG_BACKEND_PID(), CURRENT_TIMESTAMP);

Pitfalls

• The PID is OS-specific and has no meaning outside the machine running the backend. Do not use it as a cross-cluster identifier.
• In deployments with worker-style concurrency, the reported PID may be that of a pool worker rather than the original session backend. Confirm the model before relying on the PID for per-user tracing.
• PIDs are reused by the OS. A long-lived audit table that stores PIDs cannot use them to identify a historical session uniquely; combine with a timestamp.
• The function cannot be used across clusters to route queries to a specific backend; it is diagnostic only.

See Also

• pg_postmaster_start_time
• pg_conf_load_time
• inet_server_addr
• txid_current
• version