Teach isolation tester about injection points in background workers
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t53564psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 02:01 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t53564_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t53564_1 && git checkout t53564_1Patchset v1 (message #1) is on t53564_1
I hit a limitation of the isolation tester when trying to reproduce a bug in
REPACK (CONCURRENTLY) [1]/messages/by-id/29157.1774029970@localhost: it does not recognize that session is blocked due
to background worker waiting on an injection point. This patch tries to fix
that.
[1]: /messages/by-id/29157.1774029970@localhost
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
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