Re: [HACKERS] Re: pg_dump possible fix, need testers.
От | Patrick Welche |
---|---|
Тема | Re: [HACKERS] Re: pg_dump possible fix, need testers. |
Дата | |
Msg-id | 20000124233805.C29261@quartz.newn.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: pg_dump possible fix, need testers. (Alfred Perlstein <bright@wintelcom.net>) |
Ответы |
Re: [HACKERS] Re: pg_dump possible fix, need testers.
|
Список | pgsql-hackers |
On Mon, Jan 24, 2000 at 03:49:26PM -0800, Alfred Perlstein wrote: > I just ran the regression tests as best as I know how: > > ~/pgcvs/pgsql/src/test/regress % gmake runcheck > ~/pgcvs/pgsql/src/test/regress % grep FAIL run_check.out > test int2 ... FAILED > test int4 ... FAILED > test float8 ... FAILED > sequential test geometry ... FAILED > ~/pgcvs/pgsql/src/test/regress % > > no int2/int4? yipes! Not to worry, those will be differences in error message wording, but > I ran it 10 more times and one time I got: > test constraints ... FAILED What did this error come from? (cf regression.diffs) > but i got no weird parse errors or anything from the backend. > > Have you been able to find any weirdness with the fix I posted, > or is this more likely an issue with Patrick Welche's setup? I'm not sure: on the one hand, that evil join of mine returns the entire contents of a table, and the connection gets confused. Smaller joins work. Maybe it doesn't happen to you because you don't put in such a useless select (What do you want 750440 rows for?) On the other hand vacuum analyze table_name doesn't work for me but obviously does for everyone else, so at least something is wrong with my setup. Cheers, Patrick
В списке pgsql-hackers по дате отправления: