Re: Teach isolation tester about injection points in background workers - Mailing list pgsql-hackers

From Srinath Reddy Sadipiralla
Subject Re: Teach isolation tester about injection points in background workers
Date
Msg-id CAFC+b6rYYQ6CqXYYsmnLeWsCe7mDa9PhbM8=KYFB0X+XOYexEg@mail.gmail.com
Whole thread
In response to Teach isolation tester about injection points in background workers  (Antonin Houska <ah@cybertec.at>)
Responses Re: Teach isolation tester about injection points in background workers
List pgsql-hackers
Hi Antonin,

On Mon, Mar 23, 2026 at 12:52 PM Antonin Houska <ah@cybertec.at> wrote:
I hit a limitation of the isolation tester when trying to reproduce a bug in
REPACK (CONCURRENTLY) [1]: it does not recognize that session is blocked due
to background worker waiting on an injection point. This patch tries to fix
that.

+1. I was thinking can we move the logic of checking if bg workers are the
reason of blocking the main backend inside pg_isolation_test_session_is_blocked
to make it cleaner, and regarding "XXX Should we use a separate query for that?"
i am confused here IIUC if we keep it as 1 query using UNION every time its for sure
that both the queries will run, which can increase more execution time but less libpq/socket
calls, but if we send as 2 queries if 1st query doesn't returns true we have to go and
check the other query, so here if 2 queries ran then execution + libpq/socket calls overhead,
so i am slightly inclined towards separating the queries , so that if 1st gets satisfied then
we don't touch the 2nd query at all, please correct me if i am wrong here :)



--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Next
From: Yugo Nagata
Date:
Subject: Re: Allow to collect statistics on virtual generated columns