pg's sqlx path builds its JS result object on a tokio blocking-pool thread (same #1824 shape) #10337

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).