Hi, On Mon, Aug 24, 2026 at 5:01 AM vignesh C <[email protected]> wrote: > > I found an issue in GetSubscriptionRelations() when a REFRESH > PUBLICATION is executed while a subscribed relation is dropped > concurrently.
Thanks for reporting and sending the patch. > GetSubscriptionRelations() scans pg_subscription_rel using the catalog > snapshot taken when the scan starts, and then looks up the relation's > relkind through the syscache. If the relation is dropped and the drop > commits, the pg_subscription_rel row can still be visible while the > corresponding pg_class row is already gone. In this case, > get_rel_relkind() returns '\0'. > > This can be reproduced with the following steps: > I have reproduced it through debugger: > > get_rel_relkind will return '\0' which causes the assertion failure at: > .... > relkind = get_rel_relkind(subrel->srrelid); > > Assert(relkind == RELKIND_SEQUENCE || relkind == RELKIND_RELATION || > relkind == RELKIND_PARTITIONED_TABLE); How easy is it to hit this with direct SQL without a debugger or injection point? In production builds (no assertions), what happens when the relation is concurrently dropped? Does the logical replication worker error or crash, and if it exits, does it recover in the next cycle since the relation won't be in the list anymore? 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. 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? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
