Greenplum的gpcheckcat是用来检查system catalog的一致性的命令，其中有专门针对磁盘文件的检查（$GPHOME/bin/lib/gpcheckcat -R persistent -p 5432 databasename），主要是对于system catalog里关于磁盘文件的记录与实际磁盘文件的情况的一致性检查。本文结合一个实际错误介绍如何解决这类元数据错误。
现象
gpcheckcat的日志文件（比如/home/gpadmin/gpAdminLogs/gpcheckcat_20150513.log）里，最后有如下报错：
SUMMARY REPORT===================================================================Total runtime for 14 test(s): 0:44:02.24Failed test(s) that are not reported here: persistentSee /home/gpadmin/gpAdminLogs/gpcheckcat_20150513.log for detail
在检查persistent的部分，可以发现如下错误：
20150513:15:49:03:007025 gpcheckcat:mdw:gpadmin-[INFO]:-[FAIL] gp_persistent_relation_node <=> filesystem20150513:15:49:03:007025 gpcheckcat:mdw:gpadmin-[ERROR]:-gp_persistent_relation_node <=> filesystem found 22896 issue(s)20150513:15:49:03:007025 gpcheckcat:mdw:gpadmin-[ERROR]:-SELECT coalesce(a.tablespace_oid, b.tablespace_oid) as tablespace_oid,coalesce(a.database_oid, b.database_oid) as database_oid,coalesce(a.relfilenode_oid, b.relfilenode_oid) as relfilenode_oid,coalesce(a.segment_file_num, b.segment_file_num) as segment_file_num,a.relfilenode_oid is null as filesystem,b.relfilenode_oid is null as persistent,b.relkind, b.relstorageFROM gp_persistent_relation_node aFULL OUTER JOIN (SELECT p.*, c.relkind, c.relstorageFROM gp_persistent_relation_node_check() pLEFT OUTER JOIN pg_class cON (p.relfilenode_oid = c.relfilenode)WHERE (p.segment_file_num = 0 or c.relstorage != ‘h’)) b ON (a.tablespace_oid = b.tablespace_oid anda.database_oid= b.database_oidanda.relfilenode_oid = b.relfilenode_oid anda.segment_file_num = b.segment_file_num)WHERE (a.relfilenode_oid is null OR(a.persistent_state = 2 and b.relfilenode_oid is null)) andcoalesce(a.database_oid, b.database_oid) in (SELECT oid FROM pg_database WHERE datname = current_database()UNION ALLSELECT 0);20150513:15:49:03:007025 gpcheckcat:mdw:gpadmin-[ERROR]:———20150513:15:49:03:007025 gpcheckcat:mdw:gpadmin-[ERROR]:-mdw:5432:/data/master/gpseg-120150513:15:49:03:007025 gpcheckcat:mdw:gpadmin-[ERROR]:- tablespace_oid | database_oid | relfilenode_oid | segment_file_num | filesystem | persistent | relkind | relstorage20150513:15:49:03:007025 gpcheckcat:mdw:gpadmin-[ERROR]:- 1663 | 30408 | 744321 | 0 | t | f | None | None……
日志后面将紧接着22896条记录，分布在不同的若干seg node上。
分析
对问题的分析主要就是对那段sql语句分析，尝试将这个sql简化，得到自然语言描述的含义：
由于结果中b.relkind和b.relstorage都是None（等价于null），这意味下面拆解出来语句中最终被选中的都是c.relkind和c.relstorage为null的记录，因此c.relstorage != ‘h’这个条件并不会贡献给整个大sql，所以这个子sql可以被简化，简化前后顺序如下：SELECT p.*, c.relkind, c.relstorageFROM gp_persistent_relation_node_check() ppg_class cON (p.relfilenode_oid = c.relfilenode)WHERE (p.segment_file_num = 0 or c.relstorage != ‘h’)SELECT p.* FROM gp_persistent_relation_node_check() p WHERE p.segment_file_num = 0在此实际错误中，filesystem都是true并且persistent都是false，，这意味着a.relfilenode_oid 永远是null，b.relfilenode_oid永远不是null，由于a和b是FULL OUTER JOIN，所以这意味着在此案例中，此sql得到是在b中有，而在a中没有的记录根据上述两条，这个sql在这个案例中查到的其实就是函数gp_persistent_relation_node_check()中segment_file_num=0的记录里，没有在gp_persistent_relation_node中存在的部分，由于本案例中没有append-optimized表，所以segment_file_num=0这个条件也可以忽略，（猜想后经官方证实）实际上这sql找到就是磁盘上有而system catalog中没有记录的数据文件，gp_persistent_relation_node_check()这个内置的c函数就是在扫描那些数据路径：select b.database_oid,b.relfilenode_oid,b.segment_file_num from gp_persistent_relation_node_check() b where b.relfilenode_oid not in (select relfilenode_oid from gp_persistent_relation_node);解决因为有梦，所以勇敢出发，选择出发，便只顾风雨兼程。
