Re: Logical replication can lose an update after concurrent index invalidation

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, onderkalaci(at)gmail(dot)com
Subject: Re: Logical replication can lose an update after concurrent index invalidation
Date: 2026-09-18 12:54:51
Message-ID: CAA4eK1Jvw2h7ycGDTr6YXL22BUC-TC+dbM7z3Gs+B8MnHJqDug@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 7, 2026 at 9:04 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Thu, 3 Sept 2026 at 16:15, Mihail Nikalayeu
> <mihailnikalayeu(at)gmail(dot)com> wrote:
> >
> > Zhijie, Amit, thanks for the reviews!
> >
> > > we shall mention in the comments atop the old function that it should
> > > not be used in new code anymore
> >
> > Done.
> >
>
> Couple of minor comments:
> 1) I was able to compile without this header inclusion:
> --- a/src/backend/replication/logical/worker.c
> +++ b/src/backend/replication/logical/worker.c
> @@ -249,6 +249,7 @@
>
> #include "access/genam.h"
> #include "access/commit_ts.h"
> +#include "access/htup_details.h"
> #include "access/table.h"
>

Fixed in the attached. Apart from this I changed multiple comments to
make those clear. One notable change is, I moved the newly added
boolean after localindexoid as it reads better there because then we
don't need to forward reference the fields. For back-branches, if it
needs to be moved to an earlier location then we can do that in those
versions but for HEAD and 19, the new location seems better.

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.

--
With Regards,
Amit Kapila.

Attachment Content-Type Size
v4-0001-Fix-tuple-search-during-apply-after-concurrent-in.patch application/octet-stream 27.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Osama Abdul Qader 2026-09-18 12:58:28 Re: Severe performance degradation with concurrent updates due to excessive EvalPlanQual (EPQ) re‑evaluation
Previous Message Daniel Gustafsson 2026-09-18 12:51:04 Re: Stabilize and shorten test_checksums/013_rewind test