Обсуждение: BUG #14915: Create sub-partitioning using GENERATED ALWAYS ASIDENTITY will lead to system collapse.

The following bug has been logged on the website:

Bug reference:      14915
Logged by:          pu qun
Email address:      691525127@qq.com
PostgreSQL version: 10.0
Operating system:   Red Hat Enterprise Linux Server release 6.0
Description:

Steps are as follows: 
1. create partition table: 
postgres=# create table t_list(id int not null,col int,create_time
timestamp) partition by list(mod(col,2));
CREATE TABLE

2. create sub partition table without IDENTITY column_constraint. create sub
partition table successfully: 
postgres=# create table t_list_1 partition of t_list(id,col,create_time) for
values in(0);
CREATE TABLE

3. create sub partition table with IDENTITY column_constraint. create sub
partition table failed and lead to system collapse. 
postgres=# create table t_list_2 partition of t_list(id generated always as
identity,col,create_time) for values in(0);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
!>

question：
The syntax of the partition table in manual: 
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT
EXISTS ] table_name
    PARTITION OF parent_table [ (
  { column_name [ WITH OPTIONS ] [ column_constraint [ ... ] ]
    | table_constraint }
    [, ... ]
) ] FOR VALUES partition_bound_spec
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) } [ COLLATE
collation ] [ opclass ] [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITH OIDS | WITHOUT OIDS
]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]

where column_constraint is:

[ CONSTRAINT constraint_name ]
{ NOT NULL |
  NULL |
  CHECK ( expression ) [ NO INHERIT ] |
  DEFAULT default_expr |
  GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ] |
  UNIQUE index_parameters |
  PRIMARY KEY index_parameters |
  REFERENCES reftable [ ( refcolumn ) ] [ MATCH FULL | MATCH PARTIAL | MATCH
SIMPLE ]
    [ ON DELETE action ] [ ON UPDATE action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE
]

The above column_constraint include:GENERATED { ALWAYS | BY DEFAULT } AS
IDENTITY [ ( sequence_options ) ]

However, the server connection failed in actual implementation. 
What is the reason for that? Will it be a bug? 

 

On Fri, Nov 17, 2017 at 10:52 AM,  <691525127@qq.com> wrote:
> However, the server connection failed in actual implementation.
> What is the reason for that? Will it be a bug?

This issue is already discussed here, happening as well for typed
tables (original bug is about typed tables, I bumped into the
partition bit after more testing):
https://www.postgresql.org/message-id/20171023074458.1473.25799@wrigleys.postgresql.org
There is a patch which actually blocks any hole with an error message
instead of actual support as this feature support requires a bit of
refactoring when working on constraint clauses at parsing. And that's
a work about which we are not completely sure what's the best
direction to take, so for v10 things will likely go through the road
of a feature-not-supported error.
-- 
Michael

On 2017/11/17 11:05, Michael Paquier wrote:
> On Fri, Nov 17, 2017 at 10:52 AM,  <691525127@qq.com> wrote:
>> However, the server connection failed in actual implementation.
>> What is the reason for that? Will it be a bug?
> 
> This issue is already discussed here, happening as well for typed
> tables (original bug is about typed tables, I bumped into the
> partition bit after more testing):
> https://www.postgresql.org/message-id/20171023074458.1473.25799@wrigleys.postgresql.org
> There is a patch which actually blocks any hole with an error message
> instead of actual support as this feature support requires a bit of
> refactoring when working on constraint clauses at parsing. And that's
> a work about which we are not completely sure what's the best
> direction to take, so for v10 things will likely go through the road
> of a feature-not-supported error.

Yeah, I think it would be nice to apply that patch so that 10.2 will give
an error for this usage.

Thanks,
Amit