今天给大家分享一个Greenplum 6.x某些版本的bug吧，这个事情的起因是有朋友问过来说有个GPCC的dat数据文件特别特别的大，问怎么处理。
朋友发过来的文件信息如下：
-rw-r--r-- 1 gpadmin gpadmin 1210206598517 Jan 4 21:38 gpcc_queryinfo_2022-01-04_181758.dat
-rw-r--r-- 1 gpadmin gpadmin 298794041344 Jan 5 05:00 gpcc_queryinfo.dat
总体来看，有两个dat数据文件，在gpcc中，dat文件是用于存储gpcc当前数据的临时文件，这些文件通常位于greenplum-cc-web-6.1.0/ccdata/路径下，Greenplum通过外部表的方式关联到文件并做实事查询。当文件不具有当前属性以后，会通过copy命令直接入库到gpcc对应数据库的history表中进行存储。当然这两个文件有点大，由于没有获取到具体的数据库版本信息和gpcc信息，所以我还是建议他们删除要慎重。
建议他们慎重处理是因为Greenplum 6.x有一个bug，gpcc的文件copy入库可能导致segment直接挂掉，下面展开给大家介绍一下这个bug。当然这个bug并不是GPCC的坑，以上内容只是个引子。
BUG名称：COPY导致的Greenplum 6.x版本Segment异常挂掉
该问题出现在Greenplum 6.0 - 6.7.1版本上，如果你在这些版本的数据库上使用GPCC 4.x及以上的版本，从数据库的pg_logs日志中可能看到如下错误信息：
2020-09-18 12:34:04.253914 EDT,,,p304924,th0,,,2020-09-18 12:26:44 EDT,0,con504392,cmd240,seg18,,,,,"PANIC","XX000","Unexpected internal error: Segment process received signal SIGSEGV",,,,,,,0,,,,"1 0x7f213debe630 libpthread.so.0 + 0x3debe630
2 0x829eac postgres (copy.c:5456)
3 0x82fd94 postgres (copy.c:3904)
4 0x833e30 postgres DoCopy (copy.c:1129)
5 0xa87105 postgres standard_ProcessUtility (utility.c:637)
6 0xa83711 postgres (palloc.h:158)
7 0xa8420e postgres (pquery.c:1512)
8 0xa85927 postgres PortalRun (pquery.c:1022)
9 0xa7de1e postgres (postgres.c:1377)
10 0xa82a58 postgres PostgresMain (postgres.c:5403)
"
当你在master或segment的日志中发现这个问题时，可以尝试追踪一下con
COPY gpmetrics.gpcc_queries_history FROM '/usr/local/greenplum-db/greenplum-cc-web-6.1.0/ccdata/gpcc_queryinfo_2020-09-18_123403.dat' ESCAPE E'\\\\' CSV NULL AS E'null' DELIMITER E'|' LOG ERRORS SEGMENT REJECT LIMIT 100 PERCENT;
最后总结一下，当前该BUG的出现是由于GPCC执行COPY语句导致的，但是这并不是一个针对GPCC单独的BUG。也就是说，在所有的COPY语句执行过程中，都有可能出现该问题，只是因为GPCC碰巧会频繁的执行COPY语句而触发了该问题，该错误的具体原因是：在单行错误验证模式下执行COPY FROM命令向分区表插入数据时，数据文件中存在错误格式的数据，QE不能很好的处理数据格式错误。所以大家如果遇到该问题，还是要建议规避或尽快修复。
解决方案
该BUG在Greenplum 6.8.0版本上被修复了。如果你遇到了该问题，建议尽快升级到 6.8或以上的版本。你也可以通过停止使用GPCC并在你自己的应用里面把COPY语句改为其他入库方式来规避该问题，但是还是建议尽快升级。