Teach isolation tester about injection points in background workers

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/

On Tue, Mar 24, 2026 at 04:25:47PM +0530, Srinath Reddy Sadipiralla wrote:

+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 :)

Is there a benefit in this change outside the hypothetical REPACK
CONCURRENTLY? Using separating queries may make more sense on
readability ground, at least.
--
Michael

Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Mar 24, 2026 at 04:25:47PM +0530, Srinath Reddy Sadipiralla wrote:

+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 :)

Is there a benefit in this change outside the hypothetical REPACK
CONCURRENTLY?

Not at the moment. Perhaps I shouldn't pursue this patch until there's an
injection point in the tree that needs that.

Using separating queries may make more sense on readability ground, at
least.

Agreed.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com