Panic when select from an AppendOptomised (AO) table

Products

• Greenplum
• VMware Tanzu Greenplum
• VMware Tanzu Data Suite
• VMware Tanzu Data Suite
• Pivotal Data Suite Non Production Edition

Issue/Introduction

Stack trace:

(gdb) bt
#0  0x00007fe983e6cb8f in raise () from /opt/nfs/vcf_gs_csp_prd_srdata14/35617011.bcm/packcore-coredump-2922743/lib64/libpthread.so.0
#1  0x0000000000cf4a68 in StandardHandlerForSigillSigsegvSigbus_OnMainThread (processName=<optimized out>, postgres_signal_arg=11) at elog.c:5104
#2  <signal handler called>
#3  0x00007fe980d69048 in __memmove_avx_unaligned_erms () from /opt/nfs/vcf_gs_csp_prd_srdata14/35617011.bcm/packcore-coredump-2922743/lib64/libc.so.6
#4  0x0000000000707055 in fill_val (isnull=<optimized out>, datum=<optimized out>, infomask=<optimized out>, dataP=<optimized out>, bitmask=<optimized out>, bit=<optimized out>, att=<optimized out>) at heaptuple.c:274
#5  heap_fill_tuple (bit=<optimized out>, infomask=<optimized out>, data_size=<optimized out>, data=<optimized out>, isnull=<optimized out>, values=0x7fe93746f050, tupleDesc=<optimized out>) at heaptuple.c:344
#6  heap_form_minimal_tuple (tupleDescriptor=<optimized out>, values=values@entry=0x20e69d8, isnull=<optimized out>) at heaptuple.c:1452
#7  0x0000000000d6c7e0 in SerializeTuple (slot=<optimized out>, pSerInfo=pSerInfo@entry=0x1fef418, b=b@entry=0x7fff3e989de0, tcList=tcList@entry=0x7fff3e989df0, targetRoute=targetRoute@entry=0) at tupser.c:428
#8  0x0000000000d6b350 in SendTuple (mlStates=0x1fef3b0, transportStates=0x20131c0, motNodeID=1, slot=slot@entry=0x20e6990, targetRoute=targetRoute@entry=0) at cdbmotion.c:476
#9  0x00000000009a165e in doSendTuple (outerTupleSlot=0x20e6990, node=0x20113c0, motion=0x20bac20) at nodeMotion.c:1223
#10 execMotionSender (node=0x20113c0) at nodeMotion.c:264
#11 ExecMotion (pstate=0x20113c0) at nodeMotion.c:191
#12 0x000000000095d677 in ExecProcNodeGPDB (node=0x20113c0) at execProcnode.c:645
   :
   :

or

(gdb) bt
#0  0x00007fe983e6cb8f in raise () from /opt/nfs/vcf_gs_csp_prd_srdata14/35617011.bcm/packcore-coredump-3017817/lib64/libpthread.so.0
#1  0x0000000000cf4a68 in StandardHandlerForSigillSigsegvSigbus_OnMainThread (processName=<optimized out>, postgres_signal_arg=11) at elog.c:5104
#2  <signal handler called>
#3  0x000000000110528b in hash_bytes (k=<optimized out>, keylen=<optimized out>) at hashfn.c:184
#4  0x0000000000737f28 in hash_any (keylen=<optimized out>, k=<optimized out>) at ../../../../src/include/common/hashfn.h:33
#5  hashtext (fcinfo=0x7fff3e989bc0) at hashfunc.c:286
#6  0x0000000000cf720e in FunctionCall1Coll (flinfo=flinfo@entry=0x229e1c0, collation=<optimized out>, arg1=<optimized out>) at fmgr.c:1142
#7  0x0000000000951f23 in TupleHashTableHash_internal (tb=<optimized out>, tuple=0x0) at execGrouping.c:483
#8  LookupTupleHashEntry (hashtable=hashtable@entry=0x22a4640, slot=slot@entry=0x22a16f0, isnew=isnew@entry=0x7fff3e989cdb, hash=hash@entry=0x7fff3e989cdc) at execGrouping.c:333
#9  0x000000000096e137 in lookup_hash_entries (aggstate=aggstate@entry=0x20e4590) at nodeAgg.c:2262
#10 0x000000000096e283 in agg_fill_hash_table (aggstate=aggstate@entry=0x20e4590) at nodeAgg.c:2739
#11 0x0000000000972296 in ExecAgg (pstate=0x20e4590) at nodeAgg.c:2326
#12 0x000000000095d677 in ExecProcNodeGPDB (node=0x20e4590) at execProcnode.c:645
#13 0x00000000009a1584 in ExecProcNode (node=0x20e4590) at ../../../src/include/executor/executor.h:271
#14 execMotionSender (node=0x20e42a0) at nodeMotion.c:227
#15 ExecMotion (pstate=0x20e42a0) at nodeMotion.c:191
#16 0x000000000095d677 in ExecProcNodeGPDB (node=0x20e42a0) at execProcnode.c:645
#17 0x000000000095424b in ExecProcNode (node=0x20e42a0) at ../../../src/include/executor/executor.h:271
#18 ExecutePlan (estate=estate@entry=0x20e4060, planstate=0x20e42a0, use_parallel_mode=<optimized out>, operation=operation@entry=CMD_SELECT, sendTuples=sendTuples@entry=false, numberTuples=numberTuples@entry=0, 
    direction=ForwardScanDirection, dest=0x20d5fe0, execute_once=false) at execMain.c:2672
#19 0x0000000000954c55 in ExecutePlan (execute_once=false, dest=0x20d5fe0, direction=ForwardScanDirection, numberTuples=0, sendTuples=false, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=<optimized out>, 
    estate=0x20e4060) at execMain.c:922

Cause

In Greenplum 7.3.0 and below, if an append optimized (AO) table is altered by adding or dropping a column, then a VACUUM is run on the table, it is possible that selecting particular columns will report the incorrect columns.

Resolution

Fix

The issue is expected to be fixed in Greenplum version 7.3.1 and above.