Re: [HACKERS] 6.5 cvs: can't drop table

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] 6.5 cvs: can't drop table
Дата
Msg-id 2862.927641743@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 6.5 cvs: can't drop table  (Oleg Bartunov <oleg@sai.msu.su>)
Ответы Re: [HACKERS] 6.5 cvs: can't drop table  (Oleg Bartunov <oleg@sai.msu.su>)
Re: [HACKERS] 6.5 cvs: can't drop table  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
Oleg Bartunov <oleg@sai.msu.su> writes:
> today I did some tests with current 6.5 from cvs and multiple joins.
> I did unpredictable server crashes, i.e. sometimes query works
> sometimes crashes.

I have a theory about why the results are random: the GEQO planner
deliberately uses random numbers to generate plans, so you don't
always get the same plan out of it.  Whatever bug you are seeing
occurs only for a particular plan path.  (I haven't had any luck
repeating your crash here, so the bug may be platform-specific.)

It bothers me that the GEQO results are not reliably reproducible
across platforms; that complicates debugging.  I have been thinking
about suggesting that we ought to change GEQO to use a fixed random
seed value by default, with the variable random seed being available
only as a *non default* option.  Comments anyone?

In the meantime, you could try setting up a pgsql/data/pg_geqo file
with a specific Random_Seed NNN line, and try different NNN values
until you find one that will reliably trigger the failure.  That
would help in reproducing the problem elsewhere.

> After about a hour of my experiments I can't drop table in
> my test database:

If you crash the backend enough times, you shouldn't be too surprised
that your database gets corrupted ... I think this is just collateral
damage.
        regards, tom lane


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

Предыдущее
От: "Wheeler, Alfred"
Дата:
Сообщение: unsubscribe pgsql-hackers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Heads up: does RULES regress test still work for you?