Author:     Noah Misch <noah@leadboat.com>
Commit:     Noah Misch <noah@leadboat.com>

    In parallel workers, invalidate after restoring relmapper.
    
    A relcache entry is no fresher than the relmapper data used to build it.
    The "rd_refcnt <= 1" in RelationReloadNailed() prevented user-visible
    consequences by leaving every relation !rd_isvalid at the end of this
    InvalidateSystemCaches().  Any subsequent relation usage first validated
    the relation, drawing on correct relmapper data.  Even so, reduce
    fragility by delaying invalidation until we initialize all state
    essential to rebuilding a relcache entry.
    
    Reviewed by FIXME.
    
    Discussion: https://postgr.es/m/FIXME

diff --git a/src/backend/access/transam/parallel.c b/src/backend/access/transam/parallel.c
index b042696..566ae87 100644
--- a/src/backend/access/transam/parallel.c
+++ b/src/backend/access/transam/parallel.c
@@ -1417,12 +1417,6 @@ ParallelWorkerMain(Datum main_arg)
 	PushActiveSnapshot(RestoreSnapshot(asnapspace));
 
 	/*
-	 * We've changed which tuples we can see, and must therefore invalidate
-	 * system caches.
-	 */
-	InvalidateSystemCaches();
-
-	/*
 	 * Restore current role id.  Skip verifying whether session user is
 	 * allowed to become this role and blindly restore the leader's state for
 	 * current role.
@@ -1458,6 +1452,12 @@ ParallelWorkerMain(Datum main_arg)
 	AttachSerializableXact(fps->serializable_xact_handle);
 
 	/*
+	 * We've changed tuple visibility and relmapper state, so discard all
+	 * provisional state derived from system catalogs.
+	 */
+	InvalidateSystemCaches();
+
+	/*
 	 * We've initialized all of our state now; nothing should change
 	 * hereafter.
 	 */