Re: Bug in CREATE TABLE .. LIKE .. INCLUDING STATISTICS?
Ayush Tiwari <ayushtiwari.slg01@gmail.com>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Cc: Julien Tachoires <julien@tachoires.me>, dgrowleyml@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2026-04-22T11:58:41Z
Lists: pgsql-bugs
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
Commits
-
Fix attnum remapping in generateClonedExtStatsStmt()
- a0104b4474e9 17.10 landed
- 7bb519635806 16.14 landed
- 76d15a7ee9de 15.18 landed
- 81b56b47c29d 14.23 landed
- 149c875fc20b 18.4 landed
- 6cf49e804c9b 19 (unreleased) landed