Skip to content

Conversation

andre-c-andersen
Copy link

@andre-c-andersen andre-c-andersen commented Oct 18, 2025

When adding multiple database connections, I noticed the postgres-mcp context tokens were duplicated:

image

To limit token usage for multi-connection scenarios, I added support for multiple connections:

  • DATABASE_URI works as before as a default: So we have backwards compatibility.
  • Add DATABASE_URI_* env vars for multiple connections (e.g., DATABASE_URI_APP → "app")
  • Add DATABASE_DESC_* env vars for connection descriptions visible to AI
  • Update all tools to accept required conn_name parameter
  • Add ConnectionRegistry to manage multiple connection pools
  • Display available connections in server context
  • Update tests for new connection architecture

Additional fixes:

  • Remove unnecessary connection pool invalidation during query execution. The psycopg AsyncConnectionPool already handles connection recovery automatically, so manual invalidation was redundant and caused misleading "Connection not available" errors for SQL errors (missing columns, tables, etc.)

Future work:

  • Selectively choose which connections should be restricted. I didn't find a good design for this, so currently it applies globally to all connections. It also requires a deeper security audit than I have time for right now.

  - Add DATABASE_URI_* env vars for multiple connections (e.g., DATABASE_URI_APP → "app")
  - Add DATABASE_DESC_* env vars for connection descriptions visible to AI
  - Update all tools to accept required conn_name parameter
  - Add ConnectionRegistry to manage multiple connection pools
  - Display available connections in server context
  - Update tests for new connection architecture
The psycopg AsyncConnectionPool automatically handles connection recovery by discarding broken connections and creating new ones. Manual invalidation during query execution is redundant and can cause misleading error messages for SQL errors (missing columns, tables, etc.).

The _is_valid flag should only be managed during pool lifecycle events (creation in pool_connect() and closure in close()), not during normal query execution.
@andre-c-andersen andre-c-andersen deleted the branch crystaldba:main October 18, 2025 16:53
@andre-c-andersen andre-c-andersen deleted the main branch October 18, 2025 16:53
@andre-c-andersen andre-c-andersen restored the main branch October 18, 2025 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant