| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE |
| Date: | 2026-04-28 04:21:54 |
| Message-ID: | CALj2ACU8K7N25goFBejsBMEzgt=wDuEZ0YAcS_ie4hURREiEVw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Mon, Apr 27, 2026 at 8:59 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> > I initially considered an injection point but chose polling since the
> > TAP test reproduced the bug consistently with hundreds of tables on my
> > dev system. I've now added an injection point for predictability.
> >
> > I adjusted the commit message a bit. Please find the attached v3 patch
> > for further review. Thank you!
> >
>
> Thanks Bharath. I have just one minor comment:
>
> + INJECTION_POINT("pg-get-publication-tables-build-list", NULL);
>
> Shall we name it as 'pg-get-publication-tables-list-built' to be more
> meaningful, as we are pausing after list is built.
Sure. How about pg-get-publication-tables-after-list-built? It's 42
bytes, under the INJ_NAME_MAXLEN of 64 bytes, but meaningful.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-04-28 04:25:35 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Dilip Kumar | 2026-04-28 04:20:13 | Re: Proposal: Conflict log history table for Logical Replication |