Re: DSM segment handle generation in background workers
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-10-11T03:18:40Z
Lists: pgsql-hackers
Attachments
- 0001-Use-different-random-seeds-in-all-backends.patch (application/octet-stream) patch 0001
On Tue, Oct 9, 2018 at 3:21 PM Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Tue, Oct 9, 2018 at 1:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.munro@enterprisedb.com> writes: > > > On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro > > > <thomas.munro@enterprisedb.com> wrote: > > >> That's because the bgworker startup path doesn't contain a call to > > >> srandom(...distinguishing stuff...), unlike BackendRun(). I suppose > > >> do_start_bgworker() could gain a similar call... or perhaps that call > > >> should be moved into InitPostmasterChild(). If we put it in there > > >> right after MyStartTime is assigned a new value, we could use the same > > >> incantation that PostmasterMain() uses. > > > > > Maybe something like this? > > > > I think the bit with > > > > #ifndef HAVE_STRONG_RANDOM > > random_seed = 0; > > random_start_time.tv_usec = 0; > > #endif > > > > should also be done in every postmaster child, no? If we want to hide the > > postmaster's state from child processes, we ought to hide it from all. > > Ok, here is a sketch patch with a new function InitRandomSeeds() to do > that. It is called from PostmasterMain(), InitPostmasterChild() and > InitStandaloneProcess() for consistency. Here's a version I propose to push to master and 11 tomorrow, if there are no objections. -- Thomas Munro http://www.enterprisedb.com
Commits
-
Increase the number of possible random seeds per time period.
- 5b0ce3ec334b 12.0 landed
-
Refactor pid, random seed and start time initialization.
- 197e4af9d5da 12.0 landed
-
Increase the number of different values used when seeding random().
- 98c50656cac2 9.4.0 cited