Content-Type: multipart/alternative;
 boundary="------------S5tSn7rnMiargV6j0WFzh0D4"
Message-ID: <4a8200ca-8378-653e-38ed-b2e1f1611aa6@gmail.com>
Date: Thu, 16 Feb 2023 21:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: ATTACH PARTITION seems to ignore column generation status
To: Tom Lane <tgl@sss.pgh.pa.us>, Amit Langote <amitlangote09@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>
References: <2793383.1672944799@sss.pgh.pa.us>
 <CA+HiwqEDfKy6znR_AHvH8CYgjxSo19rX3DH-3e0rgb0qsuGW_w@mail.gmail.com>
 <3016779.1673026372@sss.pgh.pa.us> <44978.1673300465@sss.pgh.pa.us>
 <CA+HiwqG0rdcU1d06KPGaeV3WLETa8oadLNK8WKmKD2KWMzRPaw@mail.gmail.com>
 <191819.1673318283@sss.pgh.pa.us> <378312.1673388786@sss.pgh.pa.us>
 <CA+HiwqE1NqnkQb1gStvWu=R5F=Hg4O=3LyDCGZmLG_0OT+uJkg@mail.gmail.com>
 <667767.1673470691@sss.pgh.pa.us>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <667767.1673470691@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4a8200ca-8378-653e-38ed-b2e1f1611aa6%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------S5tSn7rnMiargV6j0WFzh0D4
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

11.01.2023 23:58, Tom Lane wrote:
> Amit Langote<amitlangote09@gmail.com>  writes:
>> I've updated your disallow-generated-child-columns-2.patch to do this,
>> and have also merged the delta post that I had attached with my last
>> email, whose contents you sound to agree with.
> Pushed with some further work to improve the handling of multiple-
> inheritance cases.  We still need to insist that all or none of the
> parent columns are generated, but we don't have to require their
> generation expressions to be alike: that can be resolved by letting
> the child table override the expression, much as we've long done for
> plain default expressions.  (This did need some work in pg_dump
> after all.)  I'm pretty happy with where this turned out.
I've encountered a query that triggers an assert added in that commit:
CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a) STORED) PARTITION BY 
RANGE (a);
CREATE TABLE tp PARTITION OF t(b DEFAULT 1) FOR VALUES FROM (0) to (1);

Core was generated by `postgres: law regression [local] CREATE 
TABLE                                 '.
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/3152655' in core file too small.
#0  __pthread_kill_implementation (no_tid=0, signo=6, 
threadid=140460372887360) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, 
threadid=140460372887360) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140460372887360) at 
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140460372887360, signo=signo@entry=6) 
at ./nptl/pthread_kill.c:89
#3  0x00007fbf79f0e476 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#4  0x00007fbf79ef47f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x000055e76b35b322 in ExceptionalCondition (
     conditionName=conditionName@entry=0x55e76b4a2240 
"!(coldef->generated && !restdef->generated)",
     fileName=fileName@entry=0x55e76b49ec71 "tablecmds.c", 
lineNumber=lineNumber@entry=3028) at assert.c:66
#6  0x000055e76afef8c3 in MergeAttributes (schema=0x55e76d480318, 
supers=supers@entry=0x55e76d474c18,
     relpersistence=112 'p', is_partition=true, 
supconstr=supconstr@entry=0x7ffe945a3768) at tablecmds.c:3028
#7  0x000055e76aff0ef2 in DefineRelation 
(stmt=stmt@entry=0x55e76d44b2d8, relkind=relkind@entry=114 'r', ownerId=10,
     ownerId@entry=0, typaddress=typaddress@entry=0x0,
     queryString=queryString@entry=0x55e76d44a408 "CREATE TABLE tp 
PARTITION OF t(b DEFAULT 1) FOR VALUES FROM (0) to (1);") at tablecmds.c:861
...

Without asserts enables, the partition created successfully, and
INSERT INTO t VALUES(0);
SELECT * FROM t;
yields:
a | b
---+---
0 | 1
(1 row)

Is this behavior expected?

Best regards,
Alexander
--------------S5tSn7rnMiargV6j0WFzh0D4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello,<br>
      <br>
      11.01.2023 23:58, Tom Lane wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:667767.1673470691@sss.pgh.pa.us">
      <pre class="moz-quote-pre" wrap="">Amit Langote <a class="moz-txt-link-rfc2396E" href="mailto:amitlangote09@gmail.com">&lt;amitlangote09@gmail.com&gt;</a> writes:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I've updated your disallow-generated-child-columns-2.patch to do this,
and have also merged the delta post that I had attached with my last
email, whose contents you sound to agree with.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Pushed with some further work to improve the handling of multiple-
inheritance cases.  We still need to insist that all or none of the
parent columns are generated, but we don't have to require their
generation expressions to be alike: that can be resolved by letting
the child table override the expression, much as we've long done for
plain default expressions.  (This did need some work in pg_dump
after all.)  I'm pretty happy with where this turned out.
</pre>
    </blockquote>
    I've encountered a query that triggers an assert added in that
    commit:<br>
    CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a) STORED)
    PARTITION BY RANGE (a);<br>
    CREATE TABLE tp PARTITION OF t(b DEFAULT 1) FOR VALUES FROM (0) to
    (1);<br>
    <br>
    Core was generated by `postgres: law regression [local] CREATE
    TABLE                                 '.<br>
    Program terminated with signal SIGABRT, Aborted.<br>
    <br>
    warning: Section `.reg-xstate/3152655' in core file too small.<br>
    #0  __pthread_kill_implementation (no_tid=0, signo=6,
    threadid=140460372887360) at ./nptl/pthread_kill.c:44<br>
    44      ./nptl/pthread_kill.c: No such file or directory.<br>
    (gdb) bt<br>
    #0  __pthread_kill_implementation (no_tid=0, signo=6,
    threadid=140460372887360) at ./nptl/pthread_kill.c:44<br>
    #1  __pthread_kill_internal (signo=6, threadid=140460372887360) at
    ./nptl/pthread_kill.c:78<br>
    #2  __GI___pthread_kill (threadid=140460372887360,
    signo=signo@entry=6) at ./nptl/pthread_kill.c:89<br>
    #3  0x00007fbf79f0e476 in __GI_raise (sig=sig@entry=6) at
    ../sysdeps/posix/raise.c:26<br>
    #4  0x00007fbf79ef47f3 in __GI_abort () at ./stdlib/abort.c:79<br>
    #5  0x000055e76b35b322 in ExceptionalCondition (<br>
        conditionName=conditionName@entry=0x55e76b4a2240
    "!(coldef-&gt;generated &amp;&amp; !restdef-&gt;generated)", <br>
        fileName=fileName@entry=0x55e76b49ec71 "tablecmds.c",
    lineNumber=lineNumber@entry=3028) at assert.c:66<br>
    #6  0x000055e76afef8c3 in MergeAttributes (schema=0x55e76d480318,
    supers=supers@entry=0x55e76d474c18, <br>
        relpersistence=112 'p', is_partition=true,
    supconstr=supconstr@entry=0x7ffe945a3768) at tablecmds.c:3028<br>
    #7  0x000055e76aff0ef2 in DefineRelation
    (stmt=stmt@entry=0x55e76d44b2d8, relkind=relkind@entry=114 'r',
    ownerId=10, <br>
        ownerId@entry=0, typaddress=typaddress@entry=0x0, <br>
        queryString=queryString@entry=0x55e76d44a408 "CREATE TABLE tp
    PARTITION OF t(b DEFAULT 1) FOR VALUES FROM (0) to (1);") at
    tablecmds.c:861<br>
    ...<br>
    <br>
    Without asserts enables, the partition created successfully, and<br>
    INSERT INTO t VALUES(0);<br>
    SELECT * FROM t;<br>
    yields:<br>
    <span style="font-family:monospace"><span
        style="color:#000000;background-color:#ffffff;"> a | b  </span><br>
      ---+---
      <br>
      0 | 1
      <br>
      (1 row)<br>
      <br>
    </span>Is this behavior expected?<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------S5tSn7rnMiargV6j0WFzh0D4--