Tom Lane wrote:
The simple solution seems to be to add --no-locale to the initdb args in
pg_regress.sh.
Er ... what exactly does that do that setting LC_ALL=C doesn't?
Windows are ignoring locale enviroment variables so you can't do that
--
Regards
Petr Jelinek (PJMODOS)
---
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The simple solution seems to be to add --no-locale to the initdb args in
> pg_regress.sh.
Er ... what exactly does that do that setting LC_ALL=C doesn't?
regards, tom lane
---(end of broadcast)-
I have become aware that regression is failing due to ordering
differences on Windows machines in some non-English locales
(specifically, Czech, but the potential is there for more failures).
The problem seems to be that the regression suite and initdb don't do
enough between them to ensure
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I'm getting time, timetz, and horology regression failures in HEAD
> > on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
> > such as this one:
>
> I'll bet a nickel this broke it:
>
> 2005-05-25 23:48 momjian
>
>
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I'm getting time, timetz, and horology regression failures in HEAD
> on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
> such as this one:
I'll bet a nickel this broke it:
2005-05-25 23:48 momjian
* src/: backend/utils/adt/dat
I'm getting time, timetz, and horology regression failures in HEAD
on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
such as this one:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=shark&dt=2005-05-26%2004:21:00
I'm getting the same regression failures shown in that link; he
On Thu, Apr 14, 2005 at 09:52:11AM +0800, Christopher Kings-Lynne wrote:
>
> I did 'gmake distclean' and rebuild and I still get the attached failures.
What versions of PostgreSQL and FreeBSD? The FreeBSD machines in
the buildfarm look good.
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
If
Do you build in a separate directory? I do and I do have problems when
the grammars (main or plpgsql) get updated -- not sure why the derived
files from bison and flex don't get rebuilt. I just delete them by
hand. (The build directory I just rm -fr as a whole).
Yours doesn't seem like a problem
On Thu, Apr 14, 2005 at 09:52:11AM +0800, Christopher Kings-Lynne wrote:
> I did 'gmake distclean' and rebuild and I still get the attached failures.
Do you build in a separate directory? I do and I do have problems when
the grammars (main or plpgsql) get updated -- not sure why the derived
files
I did 'gmake distclean' and rebuild and I still get the attached failures.
Chris
parallel group (13 tests): text name char varchar boolean oid int8 int2 float4
int4 float8 bit numeric
boolean ... ok
char ... ok
name ... ok
varchar
OK, regression tests adjusted and cat version updated.
---
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> There should have been a catversion bump for the domain-constraints
> >> patch, but
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There should have been a catversion bump for the domain-constraints
>> patch, but there wasn't. When was your previous CVS pull?
> Several days ago at least.
Then you probably got bit by that patch --- it was applied a couple days
ago.
Tom Lane wrote:
There should have been a catversion bump for the domain-constraints
patch, but there wasn't. When was your previous CVS pull?
Several days ago at least. I use cvsup every few days to sync up. Is there a
way I can tell exactly when?
Joe
---(end of bro
Joe Conway <[EMAIL PROTECTED]> writes:
> I guess a recent change requires an initdb but no change was forced?
There should have been a catversion bump for the domain-constraints
patch, but there wasn't. When was your previous CVS pull?
regards, tom lane
-
On Sat, 2002-11-23 at 01:04, Joe Conway wrote:
> I'm getting lots of regression failures:
>
>
> 25 of 89 tests failed.
>
>
> all pretty much looking like:
>
>SELECT '' AS one, o.* FROM OID_TBL o WHERE o.f1 = 1234;
> ! ERROR: Relation "pg_c
I'm getting lots of regression failures:
25 of 89 tests failed.
all pretty much looking like:
SELECT '' AS one, o.* FROM OID_TBL o WHERE o.f1 = 1234;
! ERROR: Relation "pg_constraint_contypid_index" does not exist
SELECT '' AS five, o.* FRO
16 matches
Mail list logo
