diff --git a/src/backend/commands/sequence.c b/src/backend/commands/sequence.c
index b37fd688d3..73ab609153 100644
--- a/src/backend/commands/sequence.c
+++ b/src/backend/commands/sequence.c
@@ -545,6 +545,46 @@ SequenceChangePersistence(Oid relid, char newrelpersistence)
 	Buffer		buf;
 	HeapTupleData seqdatatuple;
 
+	/*
+	 * In binary-upgrade mode, we cannot assign a new relfilenumber to the
+	 * sequence, so the normal code path below doesn't work.  However, we
+	 * don't really need to go through all the pushups of assigning a new
+	 * relfilenumber in this mode, since there's no concern for concurrent
+	 * operations, rollback-ability, or replication.  It seems sufficient to
+	 * just summarily change the sequence's relpersistence value.
+	 */
+	if (IsBinaryUpgrade)
+	{
+		Relation	pg_class;
+		HeapTuple	tuple;
+		Form_pg_class classform;
+
+		/* Get a writable copy of the pg_class tuple for the sequence. */
+		pg_class = table_open(RelationRelationId, RowExclusiveLock);
+
+		tuple = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(relid));
+		if (!HeapTupleIsValid(tuple))
+			elog(ERROR, "could not find tuple for relation %u", relid);
+		classform = (Form_pg_class) GETSTRUCT(tuple);
+
+		/* Apply the update. */
+		classform->relpersistence = newrelpersistence;
+
+		CatalogTupleUpdate(pg_class, &tuple->t_self, tuple);
+
+		heap_freetuple(tuple);
+
+		table_close(pg_class, RowExclusiveLock);
+
+		/*
+		 * Make the pg_class row change visible.  This will cause the
+		 * sequence's relcache entry to get updated, too.
+		 */
+		CommandCounterIncrement();
+
+		return;
+	}
+
 	/*
 	 * ALTER SEQUENCE acquires this lock earlier.  If we're processing an
 	 * owned sequence for ALTER TABLE, lock now.  Without the lock, we'd