On Tue, 25 Aug 2026 at 11:03, Bharath Rupireddy <[email protected]> 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
v2-0001-Skip-relations-dropped-concurrently-in-GetSubscri.patch
Description: Binary data
