On Mon, 4 Oct 2004, Tom Lane wrote:
"Arnau Rebassa" <[EMAIL PROTECTED]> writes:
I'm using a debian linux as OS with a 2.4 kernel running on it.
Incidentally, are you reconnecting every time or is it that multiple calls
in a single session are returning the same record?
I'm reconnecting each time I want to retrieve a message.
Hmm. postmaster.c does this during startup of each backend process:
gettimeofday(&now, &tz);
srandom((unsigned int) now.tv_usec);
which would ordinarily be fairly good at mixing things up. On some
platforms I might worry that the microseconds part of gettimeofday
might only have a few bits of accuracy, but I don't think that's an
issue on Linux.
It occurs to me that you might be seeing predictability as an indirect
result of something else you are doing that somehow tends to synchronize
the backend start times. Are you connecting from a cron script that
would tend to be launched at the same relative instant within a second?
It might improve matters to make the code do something like
srandom((unsigned int) (now.tv_sec ^ now.tv_usec));
How about reading from /dev/urandom on platforms that support it?
Actually, that should be done each time the random() function
is evaluated. (I have no familiarity with the code, so please
bear with me if the suggestion is unsound). I'd even add a parameter
for "really" random data to be provided, by reading /dev/random
instead of /dev/urandom (but read(2) may block).
How about the following:
random() = random(0) = traditional random()
random(1) = best effort random() via /dev/urandom
random(2) = wait for really random bits via /dev/random
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
