aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/arrayfuncs.c
diff options
context:
space:
mode:
authorNoah Misch <noah@leadboat.com>2018-09-23 22:56:39 -0700
committerNoah Misch <noah@leadboat.com>2018-09-23 22:56:42 -0700
commit89f2b64da370e7b0737760e3282f096591d6518f (patch)
tree29a9ab29cc2c712a74f6f892e00ac71b759a0d94 /src/backend/utils/adt/arrayfuncs.c
parentb1356f18b70e566da5acd9544632db7b196b3220 (diff)
downloadpostgresql-89f2b64da370e7b0737760e3282f096591d6518f.tar.gz
postgresql-89f2b64da370e7b0737760e3282f096591d6518f.zip
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
Diffstat (limited to 'src/backend/utils/adt/arrayfuncs.c')
0 files changed, 0 insertions, 0 deletions