Expose query progress and connection id as SQL functions

[sfc-gh-mslot]

Problem

DuckDB's executor already tracks per-query progress (ClientContext::query_progress, populated when enable_progress_bar is on), but the only way to read it from outside the running query was to call duckdb_query_progress against the same duckdb_connection. There is no SQL surface for asking another session's progress, which makes it impossible for a sidecar / monitor connection to report on a running query.

Solution

Two new SQL functions registered by the duckdb_pglake extension:

-- the connection_id pgduck_server assigned to this session
-- (the same value libpq's PQbackendPID returns to the client)
SELECT pg_lake_connection_id();

-- progress for one specific session, identified by connection_id
SELECT percentage, rows_processed, total_rows_to_process
FROM pg_lake_query_progress(42);

pg_lake_query_progress(connection_id) iterates the ConnectionManager's connection list (the same pattern pg_lake_stat_activity uses), finds the session whose PgLakeQueryListener.connectionId matches the argument, and returns one row with the values from ClientContext::GetQueryProgress(). The result is empty when no session has the requested id or the matching session has no active query. Returning by id rather than as a global list keeps this function orthogonal to whatever shape pg_lake_stat_activity evolves into; if we later want progress alongside the activity columns we can extend pg_lake_stat_activity itself.

The aggregator only measures source-side scans — postgres_scan, parquet, csv, range, and so on. Sinks (CSV serialization, S3 multipart upload, parquet writer flush, COPY TO) and post-scan operators (sort, join, aggregate beyond their input) are not measured. The percentage therefore tracks "how much of the source has been read", not wall-clock progress; for COPY (SELECT FROM postgres_scan(...)) TO ... the bar can sit pinned near 100% while the destination side is still flushing.

pg_lake_connection_id() reads the current ClientContext's PgLakeQueryListener.connectionId. Behind the scenes, pgduck_server now seeds that identifier from the cancellation proc id (the random int32 it already sends in BackendKeyData) instead of the raw client socket fd. That unifies the value with libpq's PQbackendPID, makes pg_lake_stat_activity look more like real postgres pg_stat_activity, and avoids the rapid fd recycling that would otherwise let a stat snapshot taken across a couple of disconnect/reconnect cycles show the same "id" for two different sessions.

duckdb_pglake_init_connection also enables enable_progress_bar by default for every new pgduck session and disables print_progress_bar (no terminal to render to). Without this default the new function would silently return -1 / 0 / 0 even though everything else is wired up; turning the bar on lets the executor populate ClientContext::query_progress after the standard wait_time delay (default 2000ms). Clients can still issue SET enable_progress_bar = false per session to opt back out.

The progress struct's fields are atomic and DuckDB documents GetQueryProgress as safe to call from another thread, which is the same access pattern used by the C-API duckdb_query_progress.

Test plan

• Manual smoke test: pg_lake_connection_id() returns the same value as PQbackendPID(conn) from a libpq client connected to the same session.
• Manual smoke test: pg_lake_query_progress(-1) returns an empty result; pg_lake_query_progress(pg_lake_connection_id()) returns one row.
• Manual smoke test: with two psql sessions, A running COPY (SELECT FROM postgres_scan(...)) TO ... (no manual SET) and B querying pg_lake_query_progress(<id-from-stat-activity>), the percentage advances after the 2-second wait_time.
• CI: new pytest under pgduck_server/tests/pytests/test_query_progress.py covering both functions and the empty-result-for-unknown-id case.