On Mon, Aug 24, 2026 at 11:35 PM Bharath Rupireddy <[email protected]> wrote: > > If it's not easily reproducible with direct SQL, I don't think we need > to fix this at all, because none of the other places (for example, > getOwnedSequences_internal() or GetPubPartitionOptionRelations()) > handle a null relkind either. >
But they will work (as they are if checks) and as far as I can see they will do the right thing which means they will tolerate concurrent drops but if not I feel it is better to fix those as well. > 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. -- With Regards, Amit Kapila.
