Re: Teach isolation tester about injection points in background workers

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>
Cc: Antonin Houska <ah(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Teach isolation tester about injection points in background workers
Date: 2026-03-25 02:19:15
Message-ID: acNGIywkRFxmOzli@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-03-25 02:28:17 Re: [PATCH] Fix premature timeout in pg_promote() caused by signal interruptions
Previous Message Xuneng Zhou 2026-03-25 02:10:05 Re: log_checkpoints: count WAL segment creations from all processes