Skip to main content

CAP.L0.CONNECTION_POOLED — the session is multiplexed, so instance-wide facts cannot be trusted

  • Category: safety
  • Level: 0
  • Stability: stable
  • Suites: audit

The connection appears to be running through a transaction pooler — pgbouncer in transaction mode and its equivalents. Between one statement and the next, the session can be handed to a different backend.

What that costs an audit​

Most of the audit is unaffected: the schema is the schema, whichever backend reads it. What breaks is anything that is a property of a session or an instance rather than of the catalog — server settings, the backend's own identity, anything read in one statement and compared in another.

Rules that depend on those are withheld with their own reason rather than answered from a session that may not have been the same one twice.

What to do​

For an audit, connect directly rather than through the pooler. The pooler is there to serve the application's traffic; a once-a-deploy audit is not that traffic, and a direct connection makes every instance-scoped rule answerable again.

If a direct connection is not available, the findings you do get are still true — the header and this notice say which questions went unanswered.