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

Hi Julien,

On Wed, Apr 15, 2026 at 7:47 PM Julien Tachoires <julien@tachoires.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.

Please find attached 2 patches for the master branch, the first one adds
a test that triggers the problem, the 2nd one is an attempt to fix it.

I think it's better to write a 4 column test, with this it covers both
cases of lookup either returning the wrong column name or errors
out when the attnum does not exist in the child, thoughts?

something like this ....

CREATE TABLE parent_like_stats (a int, b int, c int, d int);
ALTER TABLE parent_like_stats DROP COLUMN b;
CREATE STATISTICS s_parent ON a, c FROM parent_like_stats;
CREATE TABLE child_like_stats (LIKE parent_like_stats INCLUDING STATISTICS);

other than this patches LGTM.

--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

On 2026-04-16 Th 3:44 AM, Srinath Reddy Sadipiralla wrote:

Hi Julien,

On Wed, Apr 15, 2026 at 7:47 PM Julien Tachoires <julien@tachoires.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.

Please find attached 2 patches for the master branch, the first
one adds
a test that triggers the problem, the 2nd one is an attempt to fix it.

I think it's better to write a 4 column test, with this it covers both
cases of lookup either returning the wrong column name or errors
out when the attnum does not exist in the child, thoughts?

something like this ....

CREATE TABLE parent_like_stats (a int, b int, c int, d int);
ALTER TABLE parent_like_stats DROP COLUMN b;
CREATE STATISTICS s_parent ON a, c FROM parent_like_stats;
CREATE TABLE child_like_stats (LIKE parent_like_stats INCLUDING
STATISTICS);

other than this patches LGTM.

OK, here's a version that does that in a combined patch, and adjusts the
function comments to mention we also remap the stxkeys. Releases before
18 will need a little adjustment in the test files.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

Hi Andrew,

On Tue, Apr 21, 2026 at 8:49 PM Andrew Dunstan <andrew@dunslane.net> wrote:

OK, here's a version that does that in a combined patch, and adjusts the
function comments to mention we also remap the stxkeys. Releases before 18
will need a little adjustment in the test files.

Thanks for the patch , it LGTM.

--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

Hi,

On Thu, 16 Apr 2026 at 13:14, Srinath Reddy Sadipiralla <
srinath2133@gmail.com> wrote:

Hi Julien,

On Wed, Apr 15, 2026 at 7:47 PM Julien Tachoires <julien@tachoires.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