Re: Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE

On Tue, 25 Aug 2026 at 11:03, Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)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