BUG #17680: execute alter composite type and select composite type concurrently, may cause pg coredump

The following bug has been logged on the website:

Bug reference: 17680
Logged by: kui liu
Email address: liukui(at)kingbase(dot)com(dot)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