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

Hello,

Both changes in the current patch look good to me.

At Tue, 25 Aug 2026 19:11:27 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> > I feel \"%c\" might be better than %d, like what ProcessUtilitySlow() does,
> > because the relkind is defined as char.
> >
>
> Agreed, though %d is used for the same purpose at one place in code
> but other uses %c for relkind. How about a slightly more informative
> message like: elog(ERROR, "unexpected relkind \"%c\" for relation %u
> in subscription %u", relkind, subrel->srrelid, subid)?

I may be being overly cautious, but I'm a little hesitant to use %c
here. For example, if the value happened to be the first byte of a
UTF-8 sequence, it could result in an invalidly encoded log line.

Since this error is unlikely to be seen in practice and readability is
not particularly important here, I think %d is safer. It might even be
better to change the existing uses of %c for relkind to %d for the
same reason.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center