Re: [HACKERS] Re: pg_dump possible fix, need testers.

From: Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>
To: Alfred Perlstein <bright(at)wintelcom(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
Date: 2000-01-24 23:38:05
Message-ID: 20000124233805.C29261@quartz.newn.cam.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-01-24 23:48:06 RE: [HACKERS] Happy column dropping
Previous Message Chris Bitmead 2000-01-24 23:37:00 Re: [HACKERS] Well, then you keep your darn columns