Persistent rebuild utility fails with the error "Null entries for Append-Only relation id"

Products

• VMware Tanzu Greenplum

Issue/Introduction

This article discusses running the persistent rebuild utility in Pivotal Greenplum when it fails because of the large count of Append Optimized (AO) tables present in system.

Environment

Product Version: 5.9

Resolution

The Persistent rebuild utility fails with the following error message in Pivotal Greenplum:

Null entries for Append-Only relation id <relid>, relation name test, segrelid 0, visimaprelid 0, visimapidxid 0 (cdbdatabaseinfo.c:1073)

The shared buffer memory gets loaded with all the tuples from pg_appendonly during persistent rebuild of the content.

The large count of AO tables, which overload the shared memory, causes the persistent utility to fail with the following misleading error message:

Null entries for Append-Only relation

Verify your reported relid in pg_appendonly for the values of the segrelid, visimaprelid, and visimapidxid columns.

gpadmin=# select relid,segrelid,visimaprelid,visimapidxid from pg_appendonly where relid ='test'::regclass;
 relid | segrelid | visimaprelid | visimapidxid 
-------+----------+--------------+--------------
 21159 |    21164 |        21170 |        21171

The real issue is when the persistent table rebuild is collecting AO tables from the pg_appendonly catalog table. It stores the actual tuple from the shared buffer into the hash table created by the persistent table rebuild. When shared buffers are overloaded, the pg_appendonly tuples stored in the hash table become invalid.

This issue exists in Pivotal Greenplum version 5.x only. It is fixed in Pivotal Greenplum 5.11.

The resolution to this issue in the versions before 5.11 is to increase the value of the below mentioned GUC to a value according to AO table count present in system with gpconfig and restart the database.

If you are using Pivotal Greenplum version 5.x, the resolution to this issue is to increase the value of the below GUC. Increase the value in accordance to the AO table count present in the gpconfig and restart the database:

gpconfig -c shared_buffers -v '1024MB'

Consider an AO table count of 14683 in pg_appendonly. In this case, shared_buffers can be bumped to 1024MB to run the persistent rebuild utility successfully.