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
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
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,
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
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
> > >>
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
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
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,
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
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
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
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
> >>
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
>>
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
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,
17 matches
Mail list logo