| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Teach isolation tester about injection points in background workers |
| Date: | 2026-03-30 13:29:47 |
| Message-ID: | 98380.1774877387@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-30 14:17:33 | Re: scale parallel_tuple_cost by tuple width |
| Previous Message | Andrew Dunstan | 2026-03-30 13:27:08 | scale parallel_tuple_cost by tuple width |