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

Hi,

On Mon, Aug 24, 2026 at 5:01 AM vignesh C <vignesh21(at)gmail(dot)com> 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