-
Notifications
You must be signed in to change notification settings - Fork 417
_StatementCache does not call on_remove callback when clear()'ed #416
New issue
Have a question about this project? No Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “No Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? No Sign in to your account
Comments
un-def
added a commit
to un-def/asyncpg
that referenced
this issue
Mar 19, 2019
I've added some extra checks to |
un-def
added a commit
to un-def/asyncpg
that referenced
this issue
Mar 19, 2019
elprans
pushed a commit
that referenced
this issue
Mar 19, 2019
Closed via #417. |
No Sign up for free
to join this conversation on GitHub.
Already have an account?
No Sign in to comment
uvloop?: not related
_StatementCache
on_remove
callback is called for expired entries (1) and for least recently used entries when the cache is full (2), but not whenclear()
method is called (3).Connection
sets own_maybe_gc_stmt
method (4) as a callback for_StatementCache
. The method is used to mark non-referencedPreparedStatementState
objects as closed and put them in_stmts_to_close
set to schedule to close them later (they will be closed on the server side when_cleanup_stmts
is called (5)).As noted above, the callback is not called when the cache is cleared by
_StatementCache.clear
method, therefore the statements will never be closed on the postgres side (“closed” in the meaning of theClose
frontend protocol message) and can no longer be used byasyncpg
. This leads to memory leak on the server side until the connection is closed.There are two
Connection
methods that used to drop the cache:_drop_local_statement_cache
and_drop_global_statement_cache
(6). Both of them (directly or indirectly) call_StatementCache.clear
. SomeConnection
methods (set_type_codec
,reset_type_codec
,set_builtin_type_codec
,reload_schema_state
) drop the cache unconditionally, some methods do so if the database schema has been changed (_do_execute
→ (execute
,executemany
,fetch
,fetchval
,fetchrow
)). In any case, each cache drop may increase the number of unreachable named prepared statements that eat postgres memory.Is this a bug or an expected behavior?
The text was updated successfully, but these errors were encountered: