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]> 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-25 02:19 Michael Paquier <[email protected]> parent: Srinath Reddy Sadipiralla <[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-30 13:29 Antonin Houska <[email protected]> parent: Michael Paquier <[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