Initialize random() in bootstrap/stand-alone postgres and in initdb.

This removes a difference between the standard IsUnderPostmaster
execution environment and that of --boot and --single.  In a stand-alone
backend, "SELECT random()" always started at the same seed.

On a system capable of using posix shared memory, initdb could still
conclude "selecting dynamic shared memory implementation ... sysv".
Crashed --boot or --single postgres processes orphaned shared memory
objects having names that collided with the not-actually-random names
that initdb probed.  The sysv fallback appeared after ten crashes of
--boot or --single postgres.  Since --boot and --single are rare in
production use, systems used for PostgreSQL development are the
principal candidate to notice this symptom.

Back-patch to 9.3 (all supported versions).  PostgreSQL 9.4 introduced
dynamic shared memory, but 9.3 does share the "SELECT random()" problem.

Reviewed by Tom Lane and Kyotaro HORIGUCHI.

Discussion: https://postgr.es/m/20180915221546.GA3159382@rfd.leadboat.com

Author: nmisch

src/backend/utils/init/miscinit.c

@@ -320,6 +320,14 @@ InitStandaloneProcess(const char *argv0)
 
 	MyStartTime = time(NULL);	/* set our start time in case we call elog */
 
+	/*
+	 * Initialize random() for the first time, like PostmasterMain() would.
+	 * In a regular IsUnderPostmaster backend, BackendRun() computes a
+	 * high-entropy seed before any user query.  Fewer distinct initial seeds
+	 * can occur here.
+	 */
+	srandom((unsigned int) (MyProcPid ^ MyStartTime));
+
 	/* Initialize process-local latch support */
 	InitializeLatchSupport();
 	MyLatch = &LocalLatchData;

src/bin/initdb/initdb.c

@@ -922,6 +922,9 @@ choose_dsm_implementation(void)
 #ifdef HAVE_SHM_OPEN
 	int			ntries = 10;
 
+	/* Initialize random(); this function is its only user in this program. */
+	srandom((unsigned int) (getpid() ^ time(NULL)));
+
 	while (ntries > 0)
 	{
 		uint32		handle;