supabase-js v2 abortSignal cancels the HTTP request, but does PostgREST stop the running Postgres statement?

Goal

After migrating to supabase-js v2, I want to use the documented .abortSignal(signal) option on query builders (with AbortSignal.timeout(ms)) to bound long-running PostgREST and RPC calls. The client-side behavior is clear: the pending promise rejects with a fetch-level AbortError. What I cannot determine is what happens on the server side once the HTTP connection is torn down.

Uncertainty

The documentation does not state whether PostgREST cancels the in-flight SQL statement when the client disconnects, or whether the backend keeps executing until completion. If the query keeps running, it still consumes a pooled connection and may hold locks, which matters for capacity planning on a hosted project. The fallback would be bounding work with ALTER ROLE ... SET statement_timeout for roles like authenticated, but I would rather not layer both mechanisms blindly if client aborts already propagate.

Questions

• Does a client abort or disconnect cause PostgREST (as deployed on hosted Supabase) to issue a query cancellation to Postgres, or does the statement run to completion?
• Is pg_stat_activity inspection after an aborted pg_sleep RPC a reliable way to verify this on my project, and does the answer differ for self-hosted PostgREST versions?
• Given this uncertainty, is per-role statement_timeout the recommended ceiling regardless of client-side aborts?