Skip to content

Cache server_version_info and guard against re-entrant reads#622

Open
hashhar wants to merge 1 commit into
trinodb:masterfrom
hashhar:hashhar/559-loop-sqla-meta
Open

Cache server_version_info and guard against re-entrant reads#622
hashhar wants to merge 1 commit into
trinodb:masterfrom
hashhar:hashhar/559-loop-sqla-meta

Conversation

@hashhar

@hashhar hashhar commented Jul 11, 2026

Copy link
Copy Markdown
Member

Description

The SQLAlchemy dialect exposed server_version_info as an un-cached property whose getter runs "SELECT version()" through the connection. Because the query executes via the same SQLAlchemy machinery any code that reads server_version_info while a query is in flight re-enters the getter and issues another query, recursing forever.

aws-xray-sdk is an example of this pattern.

Cache the resolved value on the dialect instance and seed the cache with None before issuing the query. A re-entrant read that arrives while the version query is in flight now returns immediately from the seeded cache instead of recursing and subsequent reads are served from the cache without additional HTTP calls.

Non-technical explanation

Cache server_version_info and guard against re-entrant reads. Fixes #559.

Release notes

( ) This is not user-visible or docs only and no release notes are required.
(x) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text:

* Fix some things. ({issue}`issuenumber`)

The SQLAlchemy dialect exposed server_version_info as an un-cached
property whose getter runs "SELECT version()" through the connection.
Because the query executes via the same SQLAlchemy machinery any code
that reads server_version_info while a query is in flight re-enters the
getter and issues another query, recursing forever.

aws-xray-sdk is an example of this pattern.

Cache the resolved value on the dialect instance and seed the cache with
None before issuing the query. A re-entrant read that arrives while the
version query is in flight now returns immediately from the seeded cache
instead of recursing and subsequent reads are served from the cache
without additional HTTP calls.
@hashhar hashhar force-pushed the hashhar/559-loop-sqla-meta branch from 387b737 to 2452316 Compare July 11, 2026 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

Infinite version request loop (FastAPI with SQLAlchemy hitting a Trino docker desktop container)

1 participant