Problem
The sqlx-based pg path has the same defect as js_ioredis_hgetall (a separate issue): rows_to_pg_result calls alloc_string, js_array_alloc and js_object_alloc_with_shape inside the spawn_blocking closure, in js_pg_client_query, js_pg_client_query_params and js_pg_pool_query. This is the same #1824-shaped hazard — GC-managed allocation happening off the owning thread.
Status
Fixed for clients that take the (unmerged) turnloop transport path added by Perry's P7 lane. The currently-shipping legacy sqlx/spawn_blocking path — which is the one shipping today — still has this exposure, in three separate entry points.
What would fix it
Same fix as the ioredis sibling: return owned Rust data from the blocking closure and allocate the JS-visible object back on the owning thread, for all three affected entry points (js_pg_client_query, js_pg_client_query_params, js_pg_pool_query).
Problem
The
sqlx-basedpgpath has the same defect asjs_ioredis_hgetall(a separate issue):rows_to_pg_resultcallsalloc_string,js_array_allocandjs_object_alloc_with_shapeinside thespawn_blockingclosure, injs_pg_client_query,js_pg_client_query_paramsandjs_pg_pool_query. This is the same #1824-shaped hazard — GC-managed allocation happening off the owning thread.Status
Fixed for clients that take the (unmerged) turnloop transport path added by Perry's P7 lane. The currently-shipping legacy
sqlx/spawn_blockingpath — which is the one shipping today — still has this exposure, in three separate entry points.What would fix it
Same fix as the
ioredissibling: return owned Rust data from the blocking closure and allocate the JS-visible object back on the owning thread, for all three affected entry points (js_pg_client_query,js_pg_client_query_params,js_pg_pool_query).