public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Teach isolation tester about injection points in background workers.
4+ messages / 3 participants
[nested] [flat]
* [PATCH] Teach isolation tester about injection points in background workers.
@ 2026-03-21 15:32 Antonin Houska <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Antonin Houska @ 2026-03-21 15:32 UTC (permalink / raw)
When session gets blocked, the isolation tester checks if the corresponding
backend is waiting on a lock or on an injection point. If the backend launched
a background worker, the isolation tester is able to detect when the worker is
waiting on a lock - this is due to the concept of "lock groups". However, it
does not recoginze that the background worker is waiting on an injection
point.
This patch tries to fix the problem by calling
pg_isolation_test_session_is_blocked() not only for the backend, but also for
its background worker(s). The assumption is that if the backend is blocked,
and at the same time its background worker is waiting on an injection point,
then that waiting is probably the reason for the backend to be blocked.
---
src/test/isolation/isolationtester.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/test/isolation/isolationtester.c b/src/test/isolation/isolationtester.c
index 440c875b8ac..8f17ee412c9 100644
--- a/src/test/isolation/isolationtester.c
+++ b/src/test/isolation/isolationtester.c
@@ -216,15 +216,22 @@ main(int argc, char **argv)
* exactly expect concurrent use of test tables. However, autovacuum will
* occasionally take AccessExclusiveLock to truncate a table, and we must
* ignore that transient wait.
+ *
+ * If the session's backend is blocked, and if its background worker is
+ * waiting on an injection point, we assume that the injection point is
+ * the reason for the backend to be blocked. That's what we check in the
+ * second query of the UNION. XXX Should we use a separate query for that?
*/
initPQExpBuffer(&wait_query);
appendPQExpBufferStr(&wait_query,
+ "WITH blocking(res) AS ("
"SELECT pg_catalog.pg_isolation_test_session_is_blocked($1, '{");
/* The spec syntax requires at least one session; assume that here. */
appendPQExpBufferStr(&wait_query, conns[1].backend_pid_str);
for (i = 2; i < nconns; i++)
appendPQExpBuffer(&wait_query, ",%s", conns[i].backend_pid_str);
- appendPQExpBufferStr(&wait_query, "}')");
+ appendPQExpBufferStr(&wait_query, "}') UNION "
+ "SELECT pg_catalog.pg_isolation_test_session_is_blocked(pid, '{}') FROM pg_stat_activity WHERE leader_pid=$1) SELECT bool_or(res) FROM blocking");
res = PQprepare(conns[0].conn, PREP_WAITING, wait_query.data, 0, NULL);
if (PQresultStatus(res) != PGRES_COMMAND_OK)
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Teach isolation tester about injection points in background workers
@ 2026-03-24 10:55 Srinath Reddy Sadipiralla <[email protected]>
2026-03-25 02:19 ` Re: Teach isolation tester about injection points in background workers Michael Paquier <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Srinath Reddy Sadipiralla @ 2026-03-24 10:55 UTC (permalink / raw)
To: Antonin Houska <[email protected]>; +Cc: [email protected]
Hi Antonin,
On Mon, Mar 23, 2026 at 12:52 PM Antonin Houska <[email protected]> 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/
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Teach isolation tester about injection points in background workers
2026-03-24 10:55 Re: Teach isolation tester about injection points in background workers Srinath Reddy Sadipiralla <[email protected]>
@ 2026-03-25 02:19 ` Michael Paquier <[email protected]>
2026-03-30 13:29 ` Re: Teach isolation tester about injection points in background workers Antonin Houska <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Michael Paquier @ 2026-03-25 02:19 UTC (permalink / raw)
To: Srinath Reddy Sadipiralla <[email protected]>; +Cc: Antonin Houska <[email protected]>; [email protected]
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
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Teach isolation tester about injection points in background workers
2026-03-24 10:55 Re: Teach isolation tester about injection points in background workers Srinath Reddy Sadipiralla <[email protected]>
2026-03-25 02:19 ` Re: Teach isolation tester about injection points in background workers Michael Paquier <[email protected]>
@ 2026-03-30 13:29 ` Antonin Houska <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Antonin Houska @ 2026-03-30 13:29 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Srinath Reddy Sadipiralla <[email protected]>; [email protected]
Michael Paquier <[email protected]> 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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-03-30 13:29 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-21 15:32 [PATCH] Teach isolation tester about injection points in background workers. Antonin Houska <[email protected]>
2026-03-24 10:55 Re: Teach isolation tester about injection points in background workers Srinath Reddy Sadipiralla <[email protected]>
2026-03-25 02:19 ` Re: Teach isolation tester about injection points in background workers Michael Paquier <[email protected]>
2026-03-30 13:29 ` Re: Teach isolation tester about injection points in background workers Antonin Houska <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox