Re: Random not so random

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Random not so random
Дата
Msg-id 20647.1096899259@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Random not so random  ("Arnau Rebassa" <arebassa@hotmail.com>)
Ответы Re: Random not so random  (Bruno Wolff III <bruno@wolff.to>)
Re: Random not so random  (Marco Colombo <pgsql@esiway.net>)
Re: Random not so random  ("D. Stimits" <stimits@comcast.net>)
Список pgsql-general
"Arnau Rebassa" <arebassa@hotmail.com> 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));

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: "David Parker"
Дата:
Сообщение: mirroring/replication
Следующее
От: "Matthew T. O'Connor"
Дата:
Сообщение: Re: VACUUM FULL on 24/7 server