| From: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
|---|---|
| To: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com> |
| Cc: | Julien Tachoires <julien(at)tachoires(dot)me>, dgrowleyml(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Bug in CREATE TABLE .. LIKE .. INCLUDING STATISTICS? |
| Date: | 2026-04-22 11:58:41 |
| Message-ID: | CAJTYsWX5jTfC41mN7G8o05NRQdkpML-MJSB8kx3TM_u44pPb7Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On Thu, 16 Apr 2026 at 13:14, Srinath Reddy Sadipiralla <
srinath2133(at)gmail(dot)com> wrote:
> Hi Julien,
>
> On Wed, Apr 15, 2026 at 7:47 PM Julien Tachoires <julien(at)tachoires(dot)me>
> wrote:
>
>> Hi,
>>
>> One of our customer is experiencing an issue when executing CREATE TABLE
>> .. LIKE .. INCLUDING ALL; on 14, the following kind of error happens:
>> ERROR: cache lookup failed for attribute X of relation ZZZZZZ
>>
>> It seems to come from generateClonedExtStatsStmt(): get_attname()
>> appears to be called with an attribute number (attnum) that does not
>> exist.
>>
>
> yeah, i was able to reproduce and also check the flow which is the same
> as you mentioned.
>
I looked into this and the issue is in generateClonedExtStatsStmt().
It passes the child's relation OID
to get_attname() with attribute numbers from the parent's stxkeys.
With dropped columns the attnums don't match.
Julien's patch fixes that, it likely needs to be backported too.
Regards,
Ayush
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-04-22 13:44:40 | Re: Potential buffer overrun in spell.c's CheckAffix() |
| Previous Message | Andrey Borodin | 2026-04-22 11:57:26 | Re: Potential buffer overrun in spell.c's CheckAffix() |