Re: Bug in CREATE TABLE .. LIKE .. INCLUDING STATISTICS?

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

In response to

Browse pgsql-bugs by date

  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()