If there is some unused space at the end of a WAL page, because we never
split WAL record header, the WAL receiver's flush and apply positions were
reported a bit funnily. The flush position would report the end of the page,
including the unused padding, while the apply position would only go up to
the end of last WAL record on the page, excluding the padding page. If you
compare flush == apply positions, it would look as if not all of the WAL
had been applied yet, even though the difference between the pointers was
just the unused padding space.

This will get fixed in PostgreSQL 9.3, where the padding at end of WAL page
is eliminated, but until then, tweak the reporting of the apply position to
also include any end-of-page padding. That makes the flush == apply
comparison a valid way to check if all the flushed WAL has been applied,
even at page boundaries.

I believe this explains the "unable to obtain start synced LSN values
between primary and mirror" failures we've been seeing from the
gp_replica_check test. gp_replica_check waits for apply == flush, and if
the last WAL record lands at a page boundary, that condition never became
true because of the padding. (Although I'm not sure why it used to work
earlier, or did it?)