partially-fix-fast-path-locking-conflict-with-recovery.patch

diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index f2cf5c6..b5240da 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -2458,8 +2458,13 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag
 		 * less clear that our backend is certain to have performed a memory
 		 * fencing operation since the other backend set proc->databaseId.	So
 		 * for now, we test it after acquiring the LWLock just to be safe.
+		 *
+		 * But if we are the startup process we don't belong to a database but
+		 * still need to lock objects in other databases, so we can do this
+		 * optimization only in case we belong to a database.
+		 * XXX: explain why this is safe for shared tables.
 		 */
-		if (proc->databaseId != MyDatabaseId)
+		if (MyDatabaseId != InvalidOid && proc->databaseId != MyDatabaseId)
 		{
 			LWLockRelease(proc->backendLock);
 			continue;