On Tue, 25 Aug 2026 at 11:03, Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Yes, it's worth exploring all of these in the logical replication code
> (maybe separately though).
I Agree, if there is any issue, it can be handled separately.
> > > Even if we were to fix, I would just
> > > remove the assertion and continue in the loop if the relation is not
> > > what we expect. Would that work?
> >
> > As we are scanning pg_susbcription_rel unexpected relkind here (not
> > '\0', something else entirely) would probably indicate a real bug
> > worth surfacing, not silently swallowing. So, I suggest we can remove
> > assert after Vignesh's fix and have an elog(ERROR, "unexpected
> > relkind: %d", (int) relkind);. We use such an elog at other places as
> > well.
>
> Works for me, and I think both can go in one patch.
Updated
>After the relkind
> fix, replacing the assertion with an error means that in the rare
> scenario where the OID of the dropped table gets reused to create a
> relation that's not expected, we catch it. I'm all in favor of
> tightening this anyway.
The other ways this could happen are: (a) if logical replication is
extended in the future to support additional relation types, or (b) if
the system catalog is corrupted, for example by directly updating
relkind in pg_class using an UPDATE statement.
> On backpatching this fix, I think HEAD and PG19 (still in beta) are
> enough, because it's not easily reproducible with direct SQL. For the
> same reason, I'm fine with not having an injection point and a TAP
> test for this.
Yes, the injection-point test does not need to be committed. I shared
it only to make the issue easier to reproduce.
The attached v2 version patch has the changes for the same.
Regards,
Vignesh
