Re: crash 11.5~ (and 11.4)

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: crash 11.5~ (and 11.4)
Date: 2019-08-07 18:27:44
Message-ID: 20190807182744.GA9794@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 AND start_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 FROM child.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(at)\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
[...]

In response to

  • crash 11.5~ at 2019-08-07 17:30:13 from Justin Pryzby

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2019-08-07 18:28:17 Re: Problem with default partition pruning
Previous Message Bruce Momjian 2019-08-07 17:38:56 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)