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
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;
#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;