Fix DistributedLog_GetOldestXmin() if globalXmin < distributed oldestxmin

This is the same fix that was applied to DistributedLog_AdvanceOldestXmin()
in commit b26d34cd. This one is harder to hit, because
DistributedLog_GetOldestXmin() is only used by segment-local snapshots, i.e.
only by utility mode connections. I was able to reproduce it with this:

1. Added a little sleep() in GetOldestSnapshot(), before the call to
   DistributedLog_GetOldestXmin().
2. Launched pgbench in one terminal
3. Opened a utility mode connection with psql in another terminal, and
   ran some queries.

The assertion looked like this:

FATAL:  Unexpected internal error (distributedlog.c:300)
DETAIL:  FailedAssertion("!(TransactionIdFollowsOrEquals(oldestLocalXmin, result))", File: "distributedlog.c", Line: 300)

We bumped into this in the 9.4 merge, because with 9.4, SnapshotNow goes
away, and all catalog lookups use a regular MVCC snapshot instead. In the
segments, the "regular" MVCC snapshot is a segment-local snapshot,
however, so we started to exercise this codepath a lot more, and started
seeing these assertion failures occasionally.

src/backend/access/transam/distributedlog.c

@@ -297,8 +297,14 @@ DistributedLog_GetOldestXmin(TransactionId oldestLocalXmin)
 	}
 	LWLockRelease(DistributedLogControlLock);
 
-	Assert(TransactionIdFollowsOrEquals(oldestLocalXmin, result));
-	elogif(Debug_print_full_dtm, LOG, "oldestXmin is '%d'", result);
+	elogif(Debug_print_full_dtm, LOG, "oldestXmin is '%u'", result);
+
+	/*
+	 * Like in DistributedLog_AdvanceOldestXmin(), the shared oldestXmin
+	 * might already have been advanced past oldestLocalXmin.
+	 */
+	if (TransactionIdFollows(result, oldestLocalXmin))
+		result = oldestLocalXmin;
 
 	return result;
 }