Обсуждение: BUG #17680: execute alter composite type and select composite type concurrently, may cause pg coredump
BUG #17680: execute alter composite type and select composite type concurrently, may cause pg coredump
От
PG Bug reporting form
Дата:
The following bug has been logged on the website: Bug reference: 17680 Logged by: kui liu Email address: liukui@kingbase.com.cn PostgreSQL version: 15.0 Operating system: centos 7 Description: Hi, when create a composite type and select it concurrently, it may cause pg coredump probably. perform following steps can reproduce the bug first create type my_type as (a1 int, a2 varchar(50)); create sequence s1; then open 2 seesion, and one select type, the other alter type session-1 select '(1, ''abc'')'::my_type, nextval('s1'); session-2 alter type my_type alter attribute a1 set data type text; Importantly, when session-1 finish "record_in" function, then execute session-2, then pg will coredump, and its' callback like this (gdb) backtrace 12 #0 0x00007fb9f6601387 in raise () from /lib64/libc.so.6 #1 0x00007fb9f6602a78 in abort () from /lib64/libc.so.6 #2 0x0000000000b46d6c in ExceptionalCondition (conditionName=0xbc156b "false", fileName=0xbc14e9 "heaptuple.c", lineNumber=1320) at assert.c:66 #3 0x00000000004a3a17 in heap_deform_tuple (tuple=0x7ffc78c62410, tupleDesc=0x7fb9f7f60838, values=0x14c34e8, isnull=0x14d3768) at heaptuple.c:1320 #4 0x0000000000ab13dc in record_out (fcinfo=0x7ffc78c62510) at rowtypes.c:364 #5 0x0000000000b51ad9 in FunctionCall1Coll (flinfo=0x14b7d40, collation=0, arg1=21711688) at fmgr.c:1124 #6 0x0000000000b52b6d in OutputFunctionCall (flinfo=0x14b7d40, val=21711688) at fmgr.c:1561 #7 0x00000000004a63e2 in printtup (slot=0x14b7260, self=0x14b5e68) at printtup.c:357 #8 0x000000000072f98f in ExecutePlan (estate=0x14b6c38, planstate=0x14b6e60, use_parallel_mode=false, operation=CMD_SELECT, sendTuples=true, numberTuples=0, direction =ForwardScanDirection, dest=0x14b5e68, execute_once=true) at execMain.c:1667 #9 0x000000000072d51d in standard_ExecutorRun (queryDesc=0x140e168, direction=ForwardScanDirection, count=0, execute_once=true) at execMain.c:363 #10 0x000000000072d354 in ExecutorRun (queryDesc=0x140e168, direction=ForwardScanDirection, count=0, execute_once=true) at execMain.c:307 #11 0x0000000000999185 in PortalRunSelect (portal=0x14576b8, forward=true, count=0, dest=0x14b5e68) at pquery.c:924 By the way, if execute it the sql normally, reproduce hardly, but if use gdb, it's easy to trigger. I have tried pg 12, 15, 16-devel, it seems a historic bug. Best regards, liu kui