Re: BUG #5118: start-status-insert-fatal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Pedro Gimeno" <pgsql-003(at)personal(dot)formauri(dot)es>, pgsql-bugs(at)postgresql(dot)org, "Gerhard Leykam" <gel123(at)sealsystems(dot)de>
Subject: Re: BUG #5118: start-status-insert-fatal
Date: 2009-10-16 15:24:58
Message-ID: 6811.1255706698@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Well, then Tom's idea of using a random number seems pretty solid no
>> matter how you slice it. Maybe a UUID.

> A random number is looking like the best option. I'm not sure why I'd
> want to generate a perfectly good 128 bit random number and then throw
> away six of the bits to dress it up as a UUID, though. Do the
> libraries for that do enough to introduce entropy to compensate for
> the lost bits? Any other benefit I'm missing?

I was envisioning just using PostmasterRandom() (after initializing
the seed from time(NULL) as we do now). I don't think we need a
super-wide random number.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2009-10-16 15:32:41 Re: BUG #5118: start-status-insert-fatal
Previous Message Tom Lane 2009-10-16 15:11:00 Re: BUG #5121: Segmentation Fault when using pam w/ krb5