Re: Logical replication can lose an update after concurrent index invalidation - Mailing list pgsql-hackers

From vignesh C
Subject Re: Logical replication can lose an update after concurrent index invalidation
Date
Msg-id CALDaNm2XD8LHQhbW1do3ocpqb0uL-h04vppeJMeL4nz33b0Qbw@mail.gmail.com
Whole thread
In response to Re: Logical replication can lose an update after concurrent index invalidation  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, 18 Sept 2026 at 18:25, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> Also, shall we keep just one test, say Drop Index Concurrently instead
> of two as both tests do the same thing in a slightly different way? I
> have not done that but if you agree please update the patch
> accordingly.

I also felt one test should be fine.

The patch mostly looks good. I have one small comment: the tests use a
different ordering for wakeup and detach. If we retain the second
test, we could keep the ordering consistent.
+       # Release the worker.  The index it holds is no longer the identity.
+       $node_subscriber->safe_psql(
+               'postgres',
+               "SELECT
injection_points_wakeup('apply-update-before-open-indices');
+                SELECT
injection_points_detach('apply-update-before-open-indices');"
+       );

+       $node_subscriber->safe_psql(
+               'postgres',
+               "SELECT
injection_points_detach('apply-update-before-open-indices');
+                SELECT
injection_points_wakeup('apply-update-before-open-indices');"
+       );

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Serverside SNI support in libpq
Next
From: Bharath Rupireddy
Date:
Subject: Re: pg_walinspect: fix LSN validation messages and empty range handling