From 8857543c4d833c520fa9918babd50c6eb3f2bcd7 Mon Sep 17 00:00:00 2001 From: Rene Cannao Date: Wed, 22 Apr 2026 08:53:27 +0000 Subject: [PATCH] test(pgsql): identify backend via pg_stat_activity instead of pg_backend_pid() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The first CI run of pgsql-retry_guard_in_txn_on_broken_backend-t (now registered in legacy-g2) failed at "pg_terminate_backend signalled successfully" because ProxySQL intercepts pg_backend_pid() and returns its own thread_session_id (see PgSQL_Protocol.cpp:1398), not the real backend PID. Postgres server log from the failing run made this unambiguous: [239] LOG: statement: BEGIN [239] LOG: statement: SELECT pg_sleep(3) [240] LOG: statement: SELECT pg_terminate_backend(22) [240] WARNING: PID 22 is not a PostgreSQL backend process [239] LOG: statement: ROLLBACK Real backend is PID 239. "22" came from ProxySQL's fake-PID response, so the kill went nowhere, pg_sleep(3) ran to completion, and the post- fix FATAL_ERROR assertion never had a chance to be exercised — the regression guard was trivially passing the bug through. Replace the pg_backend_pid() probe with a pg_stat_activity lookup issued from the direct superuser connection: - embed a unique literal marker ("retry_guard_marker_