Re: crash 11.5~ (and 11.4) - Mailing list pgsql-hackers

I checked this still happens with max_parallel_workers_per_gather=0.
Now, I just reproduced using SELECT * FROM that table:

(gdb) p thisatt->attrelid
$4 = 2015128626

ts=# SELECT 2015128626::regclass;
regclass | child.huawei_umts_ucell_201908

(gdb) p thisatt->attnum 
$1 = 2
(gdb) p attnum # For earlier crash this is 1....
$2 = 1

ts=# \dt+ child.huawei_umts_ucell_201908
 child  | huawei_umts_ucell_201908 | table | telsasoft | 612 MB | 

\d+ child.huawei_umts_ucell_201908
 bsc6900ucell                               | text                        |           | not null |         | extended |
            | 
 
 ne_name                                    | text                        |           | not null |         | extended |
            | 
 
[...]
Partition of: huawei_umts_ucell_metrics FOR VALUES FROM ('2019-08-01 00:00:00') TO ('2019-09-01 00:00:00')
Partition constraint: ((start_time IS NOT NULL) AND (start_time >= '2019-08-01 00:00:00'::timestamp without time zone)
AND(start_time < '2019-09-01 00:00:00'::timestamp without time zone))
 
Indexes:
    "huawei_umts_ucell_201908_unique_idx" UNIQUE, btree (start_time, device_id, bsc6900ucell, ne_name,
interval_seconds)
    "huawei_umts_ucell_201908_idx" brin (start_time) WITH (autosummarize='true')
    "huawei_umts_ucell_201908_site_idx" btree (site_id)
Check constraints:
    "huawei_umts_ucell_201908_start_time_check" CHECK (start_time >= '2019-08-01 00:00:00'::timestamp without time zone
ANDstart_time < '2019-09-01 00:00:00'::timestamp without time zone)
 
Statistics objects:
    "child"."huawei_umts_ucell_201908" (ndistinct) ON bsc6900ucell, ne_name, start_time, interval_seconds, device_id
FROMchild.huawei_umts_ucell_201908
 
Options: autovacuum_analyze_threshold=2, autovacuum_analyze_scale_factor=0.005

ts=# SELECT COUNT(1) FROM pg_attribute WHERE attrelid='child.huawei_umts_ucell_201908'::regclass;
count | 560

ts=# SELECT * FROM pg_attribute WHERE attrelid='child.huawei_umts_ucell_201908'::regclass AND attnum>=0 ORDER BY
attnum;

attrelid      | 2015128626
attname       | bsc6900ucell
atttypid      | 25
attstattarget | -1
attlen        | -1
attnum        | 1
attndims      | 0
attcacheoff   | -1
atttypmod     | -1
attbyval      | f
attstorage    | x
attalign      | i
attnotnull    | t
atthasdef     | f
atthasmissing | f
attidentity   | 
attisdropped  | f
attislocal    | f
attinhcount   | 1
attcollation  | 100
attacl        | 
attoptions    | 
attfdwoptions | 
attmissingval | 

The only interesting thing about the parent/siblings is that the previous month
was partitioned with "daily" granularity.  I adjusted our threshold for that,
so that August is partitioned monthly:

    [...]
    child.huawei_umts_ucell_20190730 FOR VALUES FROM ('2019-07-30 00:00:00') TO ('2019-07-31 00:00:00'),
    child.huawei_umts_ucell_20190731 FOR VALUES FROM ('2019-07-31 00:00:00') TO ('2019-08-01 00:00:00'),
    child.huawei_umts_ucell_201908 FOR VALUES FROM ('2019-08-01 00:00:00') TO ('2019-09-01 00:00:00')

Program terminated with signal 11, Segmentation fault.
#0  0x00000000004877df in slot_deform_tuple (slot=0x22b5860, natts=554) at heaptuple.c:1465
1465                                    off = att_align_pointer(off, thisatt->attalign, -1,

(gdb) bt
#0  0x00000000004877df in slot_deform_tuple (slot=0x22b5860, natts=554) at heaptuple.c:1465
#1  0x0000000000487e4b in slot_getallattrs (slot=0x22b5860) at heaptuple.c:1626
#2  0x000000000048aab9 in printtup (slot=0x22b5860, self=0x2161b28) at printtup.c:392
#3  0x00000000008d0346 in RunFromStore (portal=0x21d5638, direction=ForwardScanDirection, count=0, dest=0x2161b28) at
pquery.c:1106
#4  0x00000000008cfe88 in PortalRunSelect (portal=0x21d5638, forward=true, count=0, dest=0x2161b28) at pquery.c:928
#5  0x00000000008cfb4c in PortalRun (portal=0x21d5638, count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x2161b28,altdest=0x2161b28, completionTag=0x7ffff5f39100 "") at pquery.c:773
 
#6  0x00000000008c9b22 in exec_simple_query (query_string=0x2160d28 "FETCH FORWARD 999 FROM _psql_cursor") at
postgres.c:1145
#7  0x00000000008cddf3 in PostgresMain (argc=1, argv=0x218bfb0, dbname=0x218beb0 "ts", username=0x218be90 "pryzbyj") at
postgres.c:4182
#8  0x000000000082a098 in BackendRun (port=0x2181ac0) at postmaster.c:4358
#9  0x0000000000829806 in BackendStartup (port=0x2181ac0) at postmaster.c:4030
#10 0x0000000000825cab in ServerLoop () at postmaster.c:1707
#11 0x00000000008255dd in PostmasterMain (argc=3, argv=0x215b9a0) at postmaster.c:1380
#12 0x000000000074ba30 in main (argc=3, argv=0x215b9a0) at main.c:228

#0  0x00000000004877df in slot_deform_tuple (slot=0x22b5860, natts=554) at heaptuple.c:1465
        thisatt = 0x22dec50
        tuple = 0x22b58a0
        tupleDesc = 0x22debc0
        values = 0x22b58c0
        isnull = 0x22b6a10
        tup = 0x263f9a0
        hasnulls = false
        attnum = 1
        tp = 0x263fa05
"\374\023\026\213^s#\347(\235=\326\321\067\032\245\321B\026}܋FS\375\244\003\065\336\277;\252O\006\065\320\353\211}F\237\373B\243\357J~\270\"\230ƣ\024xǍ\334\377\202\277S\031\375\351\003\220{\004"
        off = 583369983
        bp = 0x263f9b7
"\270\027$U}\232\246\235\004\255\331\033\006Qp\376E\316h\376\363\247\366Նgy7\311E\224~F\274\023ϋ%\216,\221\331@\024\363\233\070\275\004\254L\217t\262X\227\352\346\347\371\070\321ш\221\350fc\316\r\356\351h\275\213\230\360\203\374\023\026\213^s#\347(\235=\326\321\067\032\245\321B\026}܋FS\375\244\003\065\336\277;\252O\006\065\320\353\211}F\237\373B\243\357J~\270\"\230ƣ\024xǍ\334\377\202\277S\031\375\351\003\220{\004"
        slow = true
#1  0x0000000000487e4b in slot_getallattrs (slot=0x22b5860) at heaptuple.c:1626
        tdesc_natts = 554
        attnum = 554
        tuple = 0x22b58a0
        __func__ = "slot_getallattrs"

#2  0x000000000048aab9 in printtup (slot=0x22b5860, self=0x2161b28) at printtup.c:392
        typeinfo = 0x22debc0
        myState = 0x2161b28
        oldcontext = 0xa8e29a
        buf = 0x2161b78
        natts = 554
        i = 0
---Type <return> to continue, or q <return> to quit---
#3  0x00000000008d0346 in RunFromStore (portal=0x21d5638, direction=ForwardScanDirection, count=0, dest=0x2161b28) at
pquery.c:1106
        oldcontext = 0x21931a0
        ok = true
        forward = true
        current_tuple_count = 879
        slot = 0x22b5860
#4  0x00000000008cfe88 in PortalRunSelect (portal=0x21d5638, forward=true, count=0, dest=0x2161b28) at pquery.c:928
        queryDesc = 0x0
        direction = ForwardScanDirection
        nprocessed = 35205816
        __func__ = "PortalRunSelect"
#5  0x00000000008cfb4c in PortalRun (portal=0x21d5638, count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x2161b28,altdest=0x2161b28, completionTag=0x7ffff5f39100 "") at pquery.c:773
 
        save_exception_stack = 0x7ffff5f39240
        save_context_stack = 0x0
        local_sigjmp_buf = {{__jmpbuf = {35003176, 9176610698715214160, 4687312, 140737319770032, 0, 0,
9176610699432440144,-9176589804060397232}, __mask_was_saved = 0, __saved_mask = {__val = {
 
                36636288, 4352, 35002176, 1112, 1176, 0, 35003120, 140737319768192, 10970883, 35488536, 112, 35003176,
34999312,35003288, 35205536, 112}}}}
 
        result = false
        nprocessed = 4687312
        saveTopTransactionResourceOwner = 0x2187b88
        saveTopTransactionContext = 0x21f5d90
        saveActivePortal = 0x0
        saveResourceOwner = 0x2187b88
        savePortalContext = 0x0
        saveMemoryContext = 0x21f5d90
        __func__ = "PortalRun"
#6  0x00000000008c9b22 in exec_simple_query (query_string=0x2160d28 "FETCH FORWARD 999 FROM _psql_cursor") at
postgres.c:1145
[...]