Fix assertion failure when vacuuming an AO table in utility mode.

There's an assertion in vac_update_relstats(), that if num_tuples is
non-zero, num_pages must also be non-zero. Makes sense: if the table takes
up no space, there can't be any tuples in it. But we hit that case, on
vacuum of an AO table in the QD node in utility mode. The QD has the total
tuple counts in each AO segment in the pg_aoseg table, across the whole
cluster, but it doesn't have the physical sizes. So it reported N tuples,
but 0 bytes.

We started hitting that assertion after commit c0ce2eb9, which fixed the
rounding in RelationGuessNumberOfBlocks(), so that it now returns 0
blocks, for 0-byte relation. It used to return 1, which masked the
problem.

Fix by reporting 0 tuples and 0 blocks in the QD. That's a change from the
old behaviour, which was to report N tuples and 1 block, but it's
consistent with heap tables.
Reviewed-by: NJacob Champion <pchampion@pivotal.io>
Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>

src/backend/commands/vacuumlazy.c

@@ -1730,6 +1730,24 @@ vacuum_appendonly_fill_stats(Relation aorel, Snapshot snapshot,
 	totalbytes = eof;
 	nblocks = (uint32)RelationGuessNumberOfBlocks(totalbytes);
 
+	if (nblocks == 0 && num_tuples > 0)
+	{
+		/*
+		 * This can happen if you run VACUUM on an AO table from the QD in
+		 * utility mode. We can't get the file sizes from the segments in
+		 * utility mode, so there's not much we can do. We could return the
+		 * correct tuple count, but we'd have to make a guess on the relation
+		 * size. We can't return zero nblocks and and non-zero num_tuples,
+		 * because there's an assertion against that in vac_update_relstats(),
+		 * and it would be pretty confusing anyway.
+		 *
+		 * We choose to report the table as empty, because that's what happens
+		 * with heap tables.
+		 */
+		Assert(Gp_role == GP_ROLE_UTILITY);
+		num_tuples = 0;
+	}
+
 	AppendOnlyVisimap_Init(&visimap,
 						   aorel->rd_appendonly->visimaprelid,
 						   aorel->rd_appendonly->visimapidxid,