Re: Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE - Mailing list pgsql-hackers

From vignesh C
Subject Re: Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE
Date
Msg-id CALDaNm1RQO_y1xOcCZ22f-RB=9OfkNYZ8YX48qGtT6bfJGJVUw@mail.gmail.com
Whole thread
In response to Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Tue, 25 Aug 2026 at 19:11, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Aug 25, 2026 at 5:39 PM Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> >
> > Thanks for updating the patch. I confirmed it could fix the issue.
> >
> >
> > ```
> > +               else
> > +                       elog(ERROR, "unexpected relkind: %d", (int) relkind);
> > ```
> >
> >
> > 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)?

Here is an updated version with the message updated accordingly.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add a Nix flake
Next
From: Chao Li
Date:
Subject: Re: right() returns the whole string for the most negative n