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

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(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-07 15:34:39
Message-ID: CALDaNm1tEL3x=juBUP5VZCWEARK7bLyf5ugGmWvYwV6OtO=ZpQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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"

2) pgindent needs to be run for the modified changes:
a) pgindent shows this needs adjustment:
+ * A replica identity or primary key index
identifies the row on
+ * its own. The catalogs might no longer call
it the identity,
+ * as DROP INDEX CONCURRENTLY or REINDEX
CONCURRENTLY can commit

b) similarly here too:
+ bool idxisreplident; /* whether localindexoid is
the relation's
+ *
replica identity or primary key, rather
+ *
than an index usable for a REPLICA
+ *
IDENTITY FULL remote relation. Placed
+ *
here to fit in existing padding, which
+ *
leaves the struct layout unchanged in
+ * the
back branches. */

Regards,
Vignesh

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-09-07 15:42:42 Re: Logical replication row filter loses unchanged toasted columns
Previous Message Alexander Korotkov 2026-09-07 15:22:22 Re: Two issues leading to discrepancies in FSM data on the standby server