On Thu, Nov 15, 2018 at 4:25 AM Tom Lane wrote:
> Thomas Munro writes:
> > What do you think about the attached?
>
> I think you need to cast MyStartTimestamp to uint64 before shifting
> to ensure portable behavior of the shifts. In principle it wouldn't
> matter because the int64 sign bit is no
Thomas Munro writes:
> What do you think about the attached?
I think you need to cast MyStartTimestamp to uint64 before shifting
to ensure portable behavior of the shifts. In principle it wouldn't
matter because the int64 sign bit is nowhere near the part we care
about, but I've heard some prett
On Wed, Nov 14, 2018 at 8:52 PM Noah Misch wrote:
> On Wed, Nov 14, 2018 at 08:22:42PM +1300, Thomas Munro wrote:
> > On Wed, Nov 14, 2018 at 6:34 PM Noah Misch wrote:
> > > On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > > > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
>
On Wed, Nov 14, 2018 at 08:22:42PM +1300, Thomas Munro wrote:
> On Wed, Nov 14, 2018 at 6:34 PM Noah Misch wrote:
> > On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> > > > What counts is the ease of predicting a complete seed
On Wed, Nov 14, 2018 at 6:34 PM Noah Misch wrote:
> On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> > > What counts is the ease of predicting a complete seed. HEAD's algorithm
> > > has
> > > ~13 trivially-predictable bits, a
On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> > On Mon, Nov 12, 2018 at 09:39:01AM -0500, Tom Lane wrote:
> > > I doubt that's a good idea; to a first approximation, it would mean that
> > > half the seed depends only on the PID
On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> On Mon, Nov 12, 2018 at 09:39:01AM -0500, Tom Lane wrote:
> > Thomas Munro writes:
> > > On Mon, Nov 12, 2018 at 9:34 PM Noah Misch wrote:
> > >> Compared to the old code, the new code requires more wall time to visit
> > >> every
> > >> possi
On Mon, Nov 12, 2018 at 09:39:01AM -0500, Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Nov 12, 2018 at 9:34 PM Noah Misch wrote:
> >> Compared to the old code, the new code requires more wall time to visit
> >> every
> >> possible seed value. New code xor's the PID bits into the fastest-c
Thomas Munro writes:
> On Mon, Nov 12, 2018 at 9:34 PM Noah Misch wrote:
>> Compared to the old code, the new code requires more wall time to visit every
>> possible seed value. New code xor's the PID bits into the fastest-changing
>> timestamp bits, so only about twenty bits can vary within any
On Mon, Nov 12, 2018 at 9:34 PM Noah Misch wrote:
> On Sat, Oct 13, 2018 at 11:45:17PM +1300, Thomas Munro wrote:
> > + /* Set a different seed for random() in every backend. */
> > + srandom((unsigned int) MyProcPid ^ (unsigned int) MyStartTimestamp);
>
> > - TimestampDifference(0, po
On Sat, Oct 13, 2018 at 11:45:17PM +1300, Thomas Munro wrote:
> + /* Set a different seed for random() in every backend. */
> + srandom((unsigned int) MyProcPid ^ (unsigned int) MyStartTimestamp);
> - TimestampDifference(0, port->SessionStartTime, &secs, &usecs);
> - srandom((unsig
On Sat, Oct 13, 2018 at 11:45 PM Thomas Munro
wrote:
> On Thu, Oct 11, 2018 at 5:51 PM Tom Lane wrote:
> > The comment adjacent to the change in InitStandaloneProcess bothers me.
> > In particular, it points out that what BackendRun() is currently doing
> > creates more entropy in the process's r
On Thu, Oct 11, 2018 at 5:51 PM Tom Lane wrote:
> The comment adjacent to the change in InitStandaloneProcess bothers me.
> In particular, it points out that what BackendRun() is currently doing
> creates more entropy in the process's random seed than what you have
> here: MyStartTime is only good
Thomas Munro writes:
>> 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 obje
On Tue, Oct 9, 2018 at 3:21 PM Thomas Munro
wrote:
> On Tue, Oct 9, 2018 at 1:53 PM Tom Lane wrote:
> > Thomas Munro writes:
> > > On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
> > > wrote:
> > >> That's because the bgworker startup path doesn't contain a call to
> > >> srandom(...distinguishing
On Tue, Oct 9, 2018 at 1:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
> > wrote:
> >> That's because the bgworker startup path doesn't contain a call to
> >> srandom(...distinguishing stuff...), unlike BackendRun(). I suppose
> >> do_start_bgworke
Thomas Munro writes:
> On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
> 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
>> sho
On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
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 InitPostmast
Hello,
I noticed that every parallel worker generates the same sequence of
handles here:
/*
* Loop until we find an unused identifier for the new control
segment. We
* sometimes use 0 as a sentinel value indicating that no
control segment
* is known to exist, so
19 matches
Mail list logo
