From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] 6.5 cvs: can't drop table |
Date: | 1999-05-25 14:15:43 |
Message-ID: | 2862.927641743@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oleg Bartunov <oleg(at)sai(dot)msu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Wheeler, Alfred | 1999-05-25 14:16:24 | unsubscribe pgsql-hackers |
Previous Message | Tom Lane | 1999-05-25 14:02:19 | Re: [HACKERS] Partial fix for INSERT...SELECT problems |