| From: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com> |
|---|---|
| To: | Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Teach isolation tester about injection points in background workers |
| Date: | 2026-03-24 10:55:47 |
| Message-ID: | CAFC+b6rYYQ6CqXYYsmnLeWsCe7mDa9PhbM8=KYFB0X+XOYexEg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Antonin,
On Mon, Mar 23, 2026 at 12:52 PM Antonin Houska <ah(at)cybertec(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yugo Nagata | 2026-03-24 10:57:27 | Re: Allow to collect statistics on virtual generated columns |
| Previous Message | Hannu Krosing | 2026-03-24 10:54:40 | Re: SQL Property Graph Queries (SQL/PGQ) |