| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, kuroda(dot)hayato(at)fujitsu(dot)com, vignesh21(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE |
| Date: | 2026-08-26 05:19:30 |
| Message-ID: | CALj2ACVR_j+PCBpZxRd54y-Q=NdUxGyJ3SQ2fR+yrb2OgJdcMA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Tue, Aug 25, 2026 at 9:53 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> That said, I agree that %d would be safer if we want to make the error
> handling robust against an arbitrary/invalid byte say due to catalog
> corruption. As Vignesh pointed out, though, %c is currently the common
> convention for printing relkind, whereas %d is used only in one place.
>
> So perhaps we should keep %c in this patch and, if we want to adopt %d
> for unexpected relkind values, let's handle the existing %c usages
> consistently in a separate patch.
>
> Thoughts?
I looked at the most common and widely used path, which is
errdetail_relkind_not_supported(). It uses %c (some of these might be
user-visible errors). I prefer to go with that, so +1 to use %c in
this patch and discuss the use of %d separately if that's a concern.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2026-08-26 05:20:18 | Re: Adding a stored generated column without long-lived locks |
| Previous Message | Amit Kapila | 2026-08-26 04:53:18 | Re: Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE |