From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: DSM segment handle generation in background workers
Date: Mon, 08 Oct 2018 20:53:29 -0400
Message-ID: <17043.1539046409@sss.pgh.pa.us> (raw)
In-Reply-To: <CAEepm=1oRxe3n3a6bq23-2MQTSWagHTghPbpGJ1YcZEyZ_KWQA@mail.gmail.com>
References: <CAEepm=2eJj_6=B+2tEpGu2nf1BjthCf9nXXUouYvJJ4C5WSwhg@mail.gmail.com>
<CAEepm=1oRxe3n3a6bq23-2MQTSWagHTghPbpGJ1YcZEyZ_KWQA@mail.gmail.com>
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@enterprisedb.com
Subject: Re: DSM segment handle generation in background workers
In-Reply-To: <17043.1539046409@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox