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
Re: [HACKERS] 6.5 cvs: can't drop table |
Список | 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 по дате отправления: