Fix gp_hyperloglog typlen handling: handle cstring case properly

[reshke]

trafficstars

There is a bug in gp_hyperloglog work with different typlen. It does not handle cstring type, which typlen is -2. I dont know how to create an ordinary table with column type cstring. But index created on varchar column makes reprodution.

Reproduction differs a bit from version 6:

create table t1 (id character varying NOT NULL);
CREATE INDEX t_i ON t1 USING btree (((id)::name));
set gp_autostats_mode to onchange ;
set gp_autostats_on_change_threshold to 0;
insert into t1 values ('1111112346');

The last command fails on segment:

reshke=# insert into t1 values ('1111112346');
ERROR:  Error on receive from seg2 slice1 127.0.1.1:7004 pid=161382: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

gdb:

(gdb) bt
#0  GpMurmurHash64A (key=<optimized out>, len=-2, seed=<optimized out>) at gp_hyperloglog.c:901
#1  0x000055595406d90f in gp_hll_add_element (elen=<optimized out>, element=<optimized out>, hloglog=0x5559567b81b0) at gp_hyperloglog.c:795
#2  gp_hyperloglog_add_item (hllcounter=<optimized out>, element=<optimized out>, element@entry=93842191360936, typlen=<optimized out>, typbyval=<optimized out>, typalign=<optimized out>)
    at gp_hyperloglog.c:795
#3  0x0000555953af829a in compute_scalar_stats (stats=0x555956768e70, fetchfunc=0x555953af5440 <ind_fetch_func>, samplerows=10, totalrows=10) at analyze.c:3577
#4  0x0000555953afc54b in compute_index_stats (onerel=0x7fe9e1256138, col_context=0x55595676c930, numrows=<optimized out>, rows=0x55595679c850, nindexes=<optimized out>, indexdata=0x555956769640,
    totalrows=10) at analyze.c:1323
#5  do_analyze_rel (onerel=onerel@entry=0x7fe9e1256138, params=params@entry=0x7ffc45ca49e0, va_cols=va_cols@entry=0x0, acquirefunc=<optimized out>, relpages=<optimized out>, inh=inh@entry=false,
    in_outer_xact=<optimized out>, elevel=<optimized out>, ctx=<optimized out>) at analyze.c:952
#6  0x0000555953afdcb8 in analyze_rel_internal (ctx=0x55595669c7b8, bstrategy=0x5559566b3f00, in_outer_xact=true, va_cols=0x0, params=0x7ffc45ca49e0, relation=0x555956757600, relid=17131)
    at analyze.c:419
#7  analyze_rel (relid=relid@entry=17131, relation=relation@entry=0x555956757600, params=params@entry=0x7ffc45ca49e0, va_cols=va_cols@entry=0x0, in_outer_xact=in_outer_xact@entry=true,
    bstrategy=0x5559566b3f00, ctx=0x55595669c7b8) at analyze.c:230
#8  0x0000555953ba8679 in gp_acquire_sample_rows (fcinfo=0x555956765170) at analyzefuncs.c:141
#9  0x0000555953bdaae6 in ExecMakeFunctionResultSet (fcache=0x555956747d20, econtext=econtext@entry=0x555956746f70, argContext=0x5559567668d0, isNull=0x555956747cd8, isDone=isDone@entry=0x555956748180)
    at execSRF.c:618
#10 0x0000555953c0c500 in ExecProjectSRF (continuing=false, node=0x555956746e58) at nodeProjectSet.c:175
#11 ExecProjectSet (pstate=0x555956746e58) at nodeProjectSet.c:105
#12 0x0000555953bd6662 in ExecProcNodeGPDB (node=0x555956746e58) at execProcnode.c:645
#13 0x0000555953c255c1 in ExecProcNode (node=0x555956746e58) at ../../../src/include/executor/executor.h:271
#14 execMotionSender (node=0x555956746b48) at nodeMotion.c:227
#15 ExecMotion (pstate=0x555956746b48) at nodeMotion.c:191
#16 0x0000555953bd6662 in ExecProcNodeGPDB (node=0x555956746b48) at execProcnode.c:645
#17 0x0000555953bcb92a in ExecProcNode (node=0x555956746b48) at ../../../src/include/executor/executor.h:271
#18 ExecutePlan (estate=0x5559567468f0, planstate=0x555956746b48, use_parallel_mode=<optimized out>, operation=CMD_SELECT, sendTuples=false, numberTuples=0, direction=ForwardScanDirection,
    dest=0x555956673918, execute_once=false) at execMain.c:2672
#19 0x0000555953bcc4a6 in ExecutePlan (execute_once=false, dest=0x555956673918, direction=ForwardScanDirection, numberTuples=0, sendTuples=false, operation=CMD_SELECT, use_parallel_mode=<optimized out>,
    planstate=<optimized out>, estate=0x5559567468f0) at execMain.c:2632
#20 standard_ExecutorRun (queryDesc=0x555956695c20, direction=ForwardScanDirection, count=0, execute_once=<optimized out>) at execMain.c:922
#21 0x0000555953bcc655 in ExecutorRun (queryDesc=queryDesc@entry=0x555956695c20, direction=direction@entry=ForwardScanDirection, count=count@entry=0, execute_once=<optimized out>) at execMain.c:793
#22 0x0000555953e35e4c in PortalRunSelect (portal=0x555956727cc0, forward=<optimized out>, count=0, dest=<optimized out>) at pquery.c:1147
#23 0x0000555953e381a2 in PortalRun (portal=portal@entry=0x555956727cc0, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=<optimized out>,
    dest=dest@entry=0x555956673918, altdest=altdest@entry=0x555956673918, completionTag=0x7ffc45ca5110 "") at pquery.c:985
#24 0x0000555953e30318 in exec_mpp_query (query_string=query_string@entry=0x555956671e4b "select pg_catalog.gp_acquire_sample_rows(17131, 10000, 'f');",
    serializedPlantree=serializedPlantree@entry=0x555956671e88 "(\265/\375`\237\001\365\a", serializedPlantreelen=serializedPlantreelen@entry=264,
    serializedQueryDispatchDesc=serializedQueryDispatchDesc@entry=0x555956671f90 "(\265/\375`\016", serializedQueryDispatchDesclen=serializedQueryDispatchDesclen@entry=146) at postgres.c:1438
#25 0x0000555953e34ffa in PostgresMain (argc=<optimized out>, argv=argv@entry=0x5559566b6c20, dbname=<optimized out>, username=<optimized out>) at postgres.c:5575
#26 0x0000555953d74e7b in BackendRun (port=0x5559566a3260, port=0x5559566a3260) at postmaster.c:4985
#27 BackendStartup (port=0x5559566a3260) at postmaster.c:4662
#28 ServerLoop () at postmaster.c:2016
#29 0x0000555953d760a7 in PostmasterMain (argc=5, argv=<optimized out>) at postmaster.c:1631
#30 0x00005559539044a2 in main (argc=5, argv=0x55595666a9e0) at main.c:240
(gdb)

Here are some reminders before you submit the pull request

• [x] Add tests for the change
• [x] Document changes
• [x] Communicate in the mailing list if needed
• [x] Pass make installcheck
• [x] Review a PR in return to support the community