gpmfr list error "ValueError: invalid literal for long() with base 10"

Products

• VMware Tanzu Greenplum

Issue/Introduction

Symptoms:

When listing backups on DataDomain using gpmfr, the command fails with the following error message:

[gpadmin@host gpAdminLogs]$ gpmfr --list -v 
20170605:07:22:34:003828 gpmfr:host:gpadmin-[INFO]:-Starting gpmfr with args: --list -v 
Listing backups on local(host.test.com) Data Domain. 
Default backup directory: dd/db_dumps 
2017-May-22 02:45:23 (20170522024523) 
2017-May-22 02:56:34 (20170522025634) 
20170605:07:23:11:003828 gpmfr:sngrnp0901:gpadmin-[ERROR]:-gpmfr failed. exiting... 
Traceback (most recent call last): 
File "/usr/local/greenplum-db/lib/python/gppylib/mainUtils.py", line 281, in simple_main_locked 
exitCode = commandObject.run() 
File "/usr/local/greenplum-db/lib/python/gppylib/operations/__init__.py", line 53, in run 
self.ret = self.execute() 
File "/usr/local/greenplum-db/./bin/gpmfr.py", line 1180, in execute 
self.listBackups() 
File "/usr/local/greenplum-db/./bin/gpmfr.py", line 1315, in listBackups 
bkpSets = self.parseBackupListing(lines) 
File "/usr/local/greenplum-db/./bin/gpmfr.py", line 1255, in parseBackupListing 
size = long(m.group(5)) 
ValueError: invalid literal for long() with base 10: ''

Environment

Cause

gpmfr is using gpddboost --ls in the background to get a list of the backup files. The list is then parsed and one of the values is a size of the file.

The function, parseBackupListing located in /usr/local/greenplum-db-4.3.8.0/bin/gpmfr.py is not able to parse a 0 size file and returns an empty object. This further crashes the gpmfr tool.

List of backup files

[gpadmin@host ~]$ gpddboost --ls dd/db_dumps/20170602
20170613:04:29:32|ddboost-[DEBUG]:-Libraries were loaded successfully
20170613:04:29:32|ddboost-[INFO]:-opening LB on /home/gpadmin/DDBOOST_CONFIG
20170613:04:29:32|gpddboost-[DEBUG]:-ddp_open_dir(dnddmgt15-GTRNDC/db_dumps/20170602)

NAME MODE SIZE(bytes)
===============================================================================================
gp_dump_0_134_20170602005725.gz 775 308
gp_dump_0_133_20170602005725.gz 775 308
(...)
gp_dump_0_11_20170602081532.gz 600 308
gp_dump_0_12_20170602081532.gz 600 308
gp_dump_1_1_20170602081532.gz 600 496
gp_dump_0_19_20170602081532.gz 600 308
gp_dump_0_8_20170602081532.gz 600 308
gp_dump_0_121_20170602081532.gz 600 308
gp_cdatabase_1_1_20170602081532 777 113
gp_dump_0_4_20170602081532.gz 600 308
gp_dump_1_1_20170602081532_post_data.gz 600 196  
gp_dump_20170602081532_ao_state_file 600 0
gp_dump_20170602081532_co_state_file 600 0
gp_dump_20170602081532_last_operation 600 0

Note: Observe that gpmfr will fail on gp_dump_20170602081532_ao_state_file because it has a size of 0. 

Resolution

The current workaround is to manually remove 0 size files from the DataDomain. Use gpddboost --ls to identify the files with a size of 0.

This issue has been addressed in GPDB v4.3.13.0.