Thread

Commits

  1. Fix attnum remapping in generateClonedExtStatsStmt()

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

    Julien Tachoires <julien@tachoires.me> — 2026-04-15T10:57:18Z

    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.
    
    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.
    
    Best regards,
    
    -- 
    Julien Tachoires
    
  2. Re: Bug in CREATE TABLE .. LIKE .. INCLUDING STATISTICS?

    Srinath Reddy Sadipiralla <srinath2133@gmail.com> — 2026-04-16T07:44:39Z

    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/
    
  3. Re: Bug in CREATE TABLE .. LIKE .. INCLUDING STATISTICS?

    Andrew Dunstan <andrew@dunslane.net> — 2026-04-21T15:19:36Z

    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
    
  4. Re: Bug in CREATE TABLE .. LIKE .. INCLUDING STATISTICS?

    Srinath Reddy Sadipiralla <srinath2133@gmail.com> — 2026-04-21T15:56:49Z

    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/
    
  5. Re: Bug in CREATE TABLE .. LIKE .. INCLUDING STATISTICS?

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-04-22T11:58:41Z

    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