Re: [HACKERS] pg_regress breaks on msys

2006-07-20 Thread Hiroshi Saito

Hi Tom-san.

This is very strange.!!

$ make -s
In file included from preproc.y:6668:
pgc.c: In function `yylex':
pgc.c:1539: warning: label `find_rule' defined but not used
C:/MinGW/include/ctype.h: At top level:
pgc.c:3724: warning: `yy_flex_realloc' defined but not used
initdb.c: In function `locale_date_order':
initdb.c:2163: warning: `%x' yields only last 2 digits of year in some locales
pg_backup_tar.c: In function `_tarAddFile':
pg_backup_tar.c:1052: warning: comparison is always false due to limited range 
of data type
All of PostgreSQL successfully made. Ready to install.

$ make check
make -C ../../../src/port all
make[1]: Entering directory 
`/home/hi-saito/postgresql-8.2devel-20060720/src/port'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory 
`/home/hi-saito/postgresql-8.2devel-20060720/src/port'
make -C ../../../contrib/spi refint.dll autoinc.dll
make[1]: Entering directory 
`/home/hi-saito/postgresql-8.2devel-20060720/contrib/spi'
make[1]: `refint.dll' is up to date.
make[1]: `autoinc.dll' is up to date.
make[1]: Leaving directory 
`/home/hi-saito/postgresql-8.2devel-20060720/contrib/spi'
rm -rf ./testtablespace
mkdir ./testtablespace
./pg_regress --temp-install=./tmp_check --top-builddir=../../.. --temp-port=55432 --schedule=./parallel_schedule 
--multibyte=SQL_ASCII --load-language=plpgsql

== creating temporary installation==
== initializing database system   ==
== starting postmaster==
running on port 55432 with pid 1964
== creating database regression ==
CREATE DATABASE
ALTER DATABASE
== installing plpgsql ==
CREATE LANGUAGE
== running regression test queries==
parallel group (13 tests):  text oid varchar char name float4 int2 boolean int8 int4 float8 bit 
numeric

boolean  ... ok
char ... diff command failed with status 1: diff -w ./expected/char.out 
./results/char.out ./results/char.diff

server stopped
make: *** [check] Error 2

However,
$ ls -l results/char.diff
ls: results/char.diff: No such file or directory

Um
$ diff -w ./expected/char.out ./results/char.out
66d65
   | A
71c70
 (5 rows)
---

(4 rows)

79d77
  | A
84c82
 (6 rows)
---

(5 rows)

90a89

 | A

92c91
 (1 row)
---

(2 rows)

99a99

 | A

101c101
 (2 rows)
---

(3 rows)


$ diff -w ./expected/char.out ./results/char.out ./results/char.diff

$ ls -l results/char.diff
-rw-r--r--1 hi-saito pgsql  204 Jul 20 15:23 results/char.diff

[EMAIL PROTECTED] ~/postgresql-8.2devel-20060720/src/test/regress
$ cat results/char.diff
66d65
   | A
71c70
 (5 rows)
---

(4 rows)

79d77
  | A
84c82
 (6 rows)
---

(5 rows)

90a89

 | A

92c91
 (1 row)
---

(2 rows)

99a99

 | A

101c101
 (2 rows)
---

(3 rows)



Futhermore, tracking is required.

Regards,
Hiroshi Saito





---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] pg_regress breaks on msys

2006-07-20 Thread Tom Lane
Hiroshi Saito [EMAIL PROTECTED] writes:
 This is very strange.!!
  boolean  ... ok
  char ... diff command failed with status 1: diff -w 
 ./expected/char.out 
 ./results/char.out ./results/char.diff
 server stopped

Yes, I believe the problem is that our Windows versions of the
WIFEXITED/WEXITSTATUS macros are wrong. pg_regress is trying to verify
that the diff call didn't fail entirely (eg, diff not there or failed
to read one of the files), but the status code diff is returning for
files not the same is confusing it.

Can anyone check into what the result status conventions really are on
Windows?  I am tempted to change the macros to just swap the bytes,
but I dunno what that will do to their existing usages to check the
result of pclose() or win32_waitpid().

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] pg_regress breaks on msys

2006-07-20 Thread Hiroshi Saito
From: Tom Lane

 Hiroshi Saito [EMAIL PROTECTED] writes:
  This is very strange.!!
   boolean  ... ok
   char ... diff command failed with status 1: diff -w 
  ./expected/char.out
  ./results/char.out ./results/char.diff
  server stopped

 Yes, I believe the problem is that our Windows versions of the
 WIFEXITED/WEXITSTATUS macros are wrong. pg_regress is trying to verify
 that the diff call didn't fail entirely (eg, diff not there or failed
 to read one of the files), but the status code diff is returning for
 files not the same is confusing it.

Probably No, I also suspected it in the beginning. However, char.diff was not 
created
by some strange condition. I think that WIFEXITED showed the strange condition.
In the place which I showed above, diff makes char.diff from the Manual 
operation.
I expect that it is related to a system() call.

I am investigating in some other environments. now...
However, It does not clarify yet..:-(

Regards,
Hiroshi Saito



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 pg_regress now seems to break on Msys virtual locations:
 Example from the buildfarm: 
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snakedt=2006-07-19%2009:00:00


 == pgsql.4660/src/test/regress/log/initdb.log 
 ===
 The filename, directory name, or volume label syntax is incorrect.

 Surely this was tested when the original was prepared?

You can probably blame me instead of Magnus, because I did extensive
fooling with the quoting of the commands issued by pg_regress ... and
no, I don't have msys to test with, that's what the buildfarm is for ;-)

This error message seems pretty thoroughly unhelpful though.  Any ideas
what it's unhappy about?

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan

Tom Lane wrote:


Andrew Dunstan [EMAIL PROTECTED] writes:
 


pg_regress now seems to break on Msys virtual locations:
Example from the buildfarm: 
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snakedt=2006-07-19%2009:00:00
   




 


== pgsql.4660/src/test/regress/log/initdb.log 
===
The filename, directory name, or volume label syntax is incorrect.
   



 


Surely this was tested when the original was prepared?
   



You can probably blame me instead of Magnus, because I did extensive
fooling with the quoting of the commands issued by pg_regress ... and
no, I don't have msys to test with, that's what the buildfarm is for ;-)
 



Neither do I right now.


This error message seems pretty thoroughly unhelpful though.  Any ideas
what it's unhappy about?
 




I think we need to change the pg_regress error messages so that it 
includes the command string that failed, at least for now.


Then we might know instead of speculating.

It will be either quoting problem or a vitual path problem, I am pretty 
sure.  The old shell script ran in a bourne-shell-like manner. But 
calling system() from a C program will call the Windows command shell, 
where the quoting rules are quite different.


cheers

andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 This error message seems pretty thoroughly unhelpful though.  Any ideas
 what it's unhappy about?

 I think we need to change the pg_regress error messages so that it 
 includes the command string that failed, at least for now.

Done, but I bet it doesn't tell us anything we don't know already.

 It will be either quoting problem or a vitual path problem, I am pretty 
 sure.  The old shell script ran in a bourne-shell-like manner. But 
 calling system() from a C program will call the Windows command shell, 
 where the quoting rules are quite different.

In src/include/port.h we have

/*
 *  Win32 needs double quotes at the beginning and end of system()
 *  strings.  If not, it gets confused with multiple quoted strings.
 *  It also requires double-quotes around the executable name and
 *  any files used for redirection.  Other args can use single-quotes.
 *
 *  See the Notes section about quotes at:
 *  http://home.earthlink.net/~rlively/MANUALS/COMMANDS/C/CMD.HTM
 */

The referenced link seems to be dead :-( but AFAICS the pg_regress code
is following the stated rules.  Also, how is it getting past the make
install step which is quoting things just the same?  Puzzling.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bruce Momjian
Tom Lane wrote:
 In src/include/port.h we have
 
 /*
  *Win32 needs double quotes at the beginning and end of system()
  *strings.  If not, it gets confused with multiple quoted strings.
  *It also requires double-quotes around the executable name and
  *any files used for redirection.  Other args can use single-quotes.
  *
  *See the Notes section about quotes at:
  *http://home.earthlink.net/~rlively/MANUALS/COMMANDS/C/CMD.HTM
  */
 
 The referenced link seems to be dead :-( but AFAICS the pg_regress code
 is following the stated rules.  Also, how is it getting past the make
 install step which is quoting things just the same?  Puzzling.

I found the description somewhere else and copied it into our header
file:

 *  From http://www.computerhope.com/cmd.htm:
 *
 *  1. If all of the following conditions are met, then quote characters
 *  on the command line are preserved:
 *
 *   - no /S switch
 *   - exactly two quote characters
 *   - no special characters between the two quote characters, where special
 * is one of: ()@^|
 *   - there are one or more whitespace characters between the the two quote
 * characters
 *   - the string between the two quote characters is the name of an
 * executable file.
 *
 *   2. Otherwise, old behavior is to see if the first character is a quote
 *   character and if so, strip the leading character and remove the last
 *   quote character on the command line, preserving any text after the last
 *   quote character.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
  *  From http://www.computerhope.com/cmd.htm:
  *
  *  1. If all of the following conditions are met, then quote characters
  *  on the command line are preserved:
  *
  *   - no /S switch
  *   - exactly two quote characters
  *   - no special characters between the two quote characters, where special
  * is one of: ()@^|
  *   - there are one or more whitespace characters between the the two quote
  * characters
  *   - the string between the two quote characters is the name of an
  * executable file.

Hmm, that suggests that our code works *only* if there's white space in
all the paths !?  Seems unlikely that this description is fully correct,
or we'd have had problems before.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
   *  From http://www.computerhope.com/cmd.htm:
   *
   *  1. If all of the following conditions are met, then quote characters
   *  on the command line are preserved:
   *
   *   - no /S switch
   *   - exactly two quote characters
   *   - no special characters between the two quote characters, where special
   * is one of: ()@^|
   *   - there are one or more whitespace characters between the the two quote
   * characters
   *   - the string between the two quote characters is the name of an
   * executable file.
 
 Hmm, that suggests that our code works *only* if there's white space in
 all the paths !?  Seems unlikely that this description is fully correct,
 or we'd have had problems before.

It is saying _all_ these have to be true, and we already quote
executables, and the string, so we always have more than two quotes:

 *  Win32 needs double quotes at the beginning and end of system()
 *  strings.  If not, it gets confused with multiple quoted strings.
 *  It also requires double-quotes around the executable name and
 *  any files used for redirection.  Other args can use single-quotes.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Hmm, that suggests that our code works *only* if there's white space in
 all the paths !?  Seems unlikely that this description is fully correct,
 or we'd have had problems before.

 It is saying _all_ these have to be true, and we already quote
 executables, and the string, so we always have more than two quotes:

Well, the description is about as clear as mud, because it's not saying
which two quote characters it's talking about.  I read it as talking
about the two quote characters around any one word/pathname.  If you
think it's talking about the two quote characters we put around the
whole command (the SYSTEMQUOTE dodge), then we're certainly going to
fail the no special characters test, because all these commands use
I/O redirection symbols.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan

Tom Lane wrote:


Andrew Dunstan [EMAIL PROTECTED] writes:
 


Tom Lane wrote:
   


This error message seems pretty thoroughly unhelpful though.  Any ideas
what it's unhappy about?
 



 

I think we need to change the pg_regress error messages so that it 
includes the command string that failed, at least for now.
   



Done, but I bet it doesn't tell us anything we don't know already.
 



Well, we have a result, courtesy of a special run from Stefan: 
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorsedt=2006-07-19%2017:52:41 
has:


Command was: 
C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/bin/initdb
 -D C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/data -L 
C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql
 --noclean  --no-locale ./log/initdb.log 21


The second C:/msys/1.0/ should not be in the path to initdb.


Not sure how to fix.

cheers

andrew


 

It will be either quoting problem or a vitual path problem, I am pretty 
sure.  The old shell script ran in a bourne-shell-like manner. But 
calling system() from a C program will call the Windows command shell, 
where the quoting rules are quite different.
   



In src/include/port.h we have

/*
*   Win32 needs double quotes at the beginning and end of system()
*   strings.  If not, it gets confused with multiple quoted strings.
*   It also requires double-quotes around the executable name and
*   any files used for redirection.  Other args can use single-quotes.
*
*   See the Notes section about quotes at:
*   http://home.earthlink.net/~rlively/MANUALS/COMMANDS/C/CMD.HTM
*/

The referenced link seems to be dead :-( but AFAICS the pg_regress code
is following the stated rules.  Also, how is it getting past the make
install step which is quoting things just the same?  Puzzling.

regards, tom lane

 




---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
After looking at the presumably-working uses of system() in initdb and
pg_ctl, I have a theory about the pg_regress problem --- could it be
that Windows system() requires a space between I/O redirection symbols
and pathnames?  I see that the pre-existing code consistently puts one,
except in cases like 21:

snprintf(cmd, MAXPGPATH, %s\%s\ %s%s  \%s\  \%s\ 21 %s,
 SYSTEMQUOTE, postgres_path, pgdata_opt, post_opts,
 DEVNULL, log_file, SYSTEMQUOTE);

but there's nothing in our docs saying this is necessary ...

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Hmm, that suggests that our code works *only* if there's white space in
  all the paths !?  Seems unlikely that this description is fully correct,
  or we'd have had problems before.
 
  It is saying _all_ these have to be true, and we already quote
  executables, and the string, so we always have more than two quotes:
 
 Well, the description is about as clear as mud, because it's not saying
 which two quote characters it's talking about.  I read it as talking
 about the two quote characters around any one word/pathname.  If you
 think it's talking about the two quote characters we put around the
 whole command (the SYSTEMQUOTE dodge), then we're certainly going to
 fail the no special characters test, because all these commands use
 I/O redirection symbols.

Right, the top says:

 *  1. If all of the following conditions are met, then quote characters
 *  on the _command_ _line_ are preserved:

It is talking about the entire command string, because this is system()
and there is no distinction between commands and arguments --- it is one
big string.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 Command was: 
 C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/bin/initdb
  -D 
 C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/data
  -L 
 C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql
  --noclean  --no-locale ./log/initdb.log 21

 The second C:/msys/1.0/ should not be in the path to initdb.

Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR
after that instead of before it?  What we need is a way to determine the
paths that make install used ...

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bort, Paul
 Andrew Dunstan [EMAIL PROTECTED] writes:
   
 
 Well, we have a result, courtesy of a special run from Stefan: 
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorsedt=
 2006-07-19%2017:52:41 
 has:
 
 Command was: 
 C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test
 /regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbu
 ild/HEAD/inst/bin/initdb -D 
 C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/
 regress/./tmp_check/data -L 
 C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/
 regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbui
 ld/HEAD/inst/share/postgresql --noclean  --no-locale 
 ./log/initdb.log 21
 
 
 The second C:/msys/1.0/ should not be in the path to initdb.
 

Andrew's on to something, I think. Colons are verboten anywhere in a
filename except position 2, right after a drive letter. The path to
postgresql later in the command will also have problems.

Regards,
Paul Bort
 

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote:
 Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR
 after that instead of before it?  What we need is a way to determine the
 paths that make install used ...

AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir
etc, for instance this is how initdb/Makefile installs initdb:

$(INSTALL_PROGRAM) initdb$(X) '$(DESTDIR)$(bindir)/initdb$(X)'

The evidence at hand says that this should produce exactly the same path
string as pg_regress is then using to call initdb.  So the question in
my mind now is how come the make install step isn't failing.  For that
matter, this same path-construction technique was used by the
shellscript... so how come it worked before?

It would be simple enough to make pg_regress strip off a drive letter
from the path strings it receives from the Makefile, but I'm not seeing
a principled way to discover that the /msys/1.0/ part has to go.  How
are the makefiles managing to generate a different value of $(bindir) at
install time than what was passed into pg_regress at build time?

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan

Tom Lane wrote:


I wrote:
 


Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR
after that instead of before it?  What we need is a way to determine the
paths that make install used ...
   



AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir
etc, for instance this is how initdb/Makefile installs initdb:

$(INSTALL_PROGRAM) initdb$(X) '$(DESTDIR)$(bindir)/initdb$(X)'

The evidence at hand says that this should produce exactly the same path
string as pg_regress is then using to call initdb.  So the question in
my mind now is how come the make install step isn't failing.  For that
matter, this same path-construction technique was used by the
shellscript... so how come it worked before?

It would be simple enough to make pg_regress strip off a drive letter
from the path strings it receives from the Makefile, but I'm not seeing
a principled way to discover that the /msys/1.0/ part has to go.  How
are the makefiles managing to generate a different value of $(bindir) at
install time than what was passed into pg_regress at build time?

regards, tom lane

 



I think we'll need to have the makefile tell us what it thinks the cwd 
is, so if it's a virtual path we'll be able to use that.


Compare the install log on the 8.1 branch (from our new buildfarm member 
bandicoot) here  
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=bandicootdt=2006-07-19%2009%3A52%3A28stg=check 

with what seahorse is showing. Note that the install does not involve 
windows paths at all - just Msys virtual paths. But we do need to use 
Windows paths for the data files.


cheers

andrew



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 I think we'll need to have the makefile tell us what it thinks the cwd 
 is, so if it's a virtual path we'll be able to use that.

I don't see where cwd enters into it.  The thing I don't understand is
that the value of the make variable $(bindir) is apparently changing.
How can it, when it's been hard-wired into Makefile.global by configure?

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote:
 I don't see where cwd enters into it.  The thing I don't understand is
 that the value of the make variable $(bindir) is apparently changing.
 How can it, when it's been hard-wired into Makefile.global by configure?

After some googling I gather that msys' make has been hacked to
transform paths between actual Windows paths and virtual paths
at what-they-think-are-strategic spots.  If this is correct, then
I think our problem is that the method I used to inject the values
of $(bindir) and friends into pg_regress.c ends up supplying actual
Windows paths, where we would much rather it supplied virtual paths.

An alternative method I had considered using was to have pg_regress.c
get the paths by #including pg_config_paths.h.  Can anyone say whether
pg_config_paths.h receives real or virtual paths when building under
mingw?

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan

Tom Lane wrote:

I wrote:
  

I don't see where cwd enters into it.  The thing I don't understand is
that the value of the make variable $(bindir) is apparently changing.
How can it, when it's been hard-wired into Makefile.global by configure?



After some googling I gather that msys' make has been hacked to
transform paths between actual Windows paths and virtual paths
at what-they-think-are-strategic spots.  If this is correct, then
I think our problem is that the method I used to inject the values
of $(bindir) and friends into pg_regress.c ends up supplying actual
Windows paths, where we would much rather it supplied virtual paths.



  


Unless it also lies on the echoed command line this seems an 
unconvincing explanation. The seahorse log says:


gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing  -I../../../src/include 
-I./src/include/port/win32 -DEXEC_BACKEND  -I/c/tcl/include -I../../../src/include/port/win32 
'-DPGBINDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/bin' '-DLIBDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/lib' 
'-DPGSHAREDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql' '-DHOST_TUPLE=i686-pc-mingw32' 
'-DMAKEPROG=make' '-DSHELLPROG=/bin/sh.exe' -c -o pg_regress.o pg_regress.c



If those -D values are not what it gets then that would be quite evil.

We used to pass these values almost same way when we first did initdb in 
C, and I don't recall any such problems. We had:


override CPPFLAGS := -DPGBINDIR=\$(*bindir*)\ -DPGDATADIR=\$(*datadir*)\ 
-DFRONTEND -I$(*libpq_srcdir*) $(*CPPFLAGS*)


There is also this warning, by the way:

pg_regress.c:63: warning: 'shellprog' defined but not used


cheers


andrew



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 Unless it also lies on the echoed command line this seems an 
 unconvincing explanation. The seahorse log says:

 gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline 
 -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing  
 -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND  
 -I/c/tcl/include -I../../../src/include/port/win32 
 '-DPGBINDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/bin' 
 '-DLIBDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/lib' 
 '-DPGSHAREDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql' 
 '-DHOST_TUPLE=i686-pc-mingw32' '-DMAKEPROG=make' 
 '-DSHELLPROG=/bin/sh.exe' -c -o pg_regress.o pg_regress.c

 If those -D values are not what it gets then that would be quite evil.

Indeed ... but if those *are* what it gets then how can you explain the
constructed paths?

I just committed a change to extract the paths via pg_config_paths.h.
If that doesn't fix it then I guess the next thing is to put in some
debug printout to show what values are really getting compiled in :-(

 We used to pass these values almost same way when we first did initdb in 
 C, and I don't recall any such problems. We had:

 override CPPFLAGS := -DPGBINDIR=\$(*bindir*)\ -DPGDATADIR=\$(*datadir*)\ 
 -DFRONTEND -I$(*libpq_srcdir*) $(*CPPFLAGS*)

That seems a bit interesting.  What are the stars for?  I don't see
anything about a syntax like that in my gmake documentation.

 There is also this warning, by the way:
 pg_regress.c:63: warning: 'shellprog' defined but not used

Good catch, fix committed.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote:
 I just committed a change to extract the paths via pg_config_paths.h.
 If that doesn't fix it then I guess the next thing is to put in some
 debug printout to show what values are really getting compiled in :-(

Seems that *did* fix it, which opens a whole new set of questions about
how much you can trust msys' make.  However, the latest seahorse results
show we still have a bug or two:

 oidjoins ... ok
 type_sanity  ... ok
 opr_sanity   ... ok
test geometry ... server stopped
diff command failed: diff -w ./expected/geometry.out 
./results/geometry.out ./results/geometry.diff
make: *** [check] Error 2

What I think happened here is that diff reported a difference and
pg_regress misinterpreted the exit status as being a hard failure.
Can someone check on whether it's possible to tell the difference
between these cases with Windows diff ?

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan

Tom Lane wrote:
We used to pass these values almost same way when we first did initdb in 
C, and I don't recall any such problems. We had:



  

override CPPFLAGS := -DPGBINDIR=\$(*bindir*)\ -DPGDATADIR=\$(*datadir*)\ 
-DFRONTEND -I$(*libpq_srcdir*) $(*CPPFLAGS*)



That seems a bit interesting.  What are the stars for?  I don't see
anything about a syntax like that in my gmake documentation.

  


The stars are from my MUA not handling CP from formatted text as well 
as it should in text mode. It should have read:


override CPPFLAGS := -DPGBINDIR=\$(bindir)\ -DPGDATADIR=\$(datadir)\ 
-DFRONTEND -I$(libpq_srcdir) $(CPPFLAGS)


cheers

andrew






---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote:
 What I think happened here is that diff reported a difference and
 pg_regress misinterpreted the exit status as being a hard failure.
 Can someone check on whether it's possible to tell the difference
 between these cases with Windows diff ?

So the latest result shows that the return value from system() is
in fact 1:

 type_sanity  ... ok
 opr_sanity   ... ok
test geometry ... diff command failed with status 1: diff -w 
./expected/geometry.out ./results/geometry.out ./results/geometry.diff
server stopped


What I am now wondering is why win32.h defines WIFEXITED and WEXITSTATUS
the way it does.  We have not previously been using those macros to test
the result of system() --- at least not in any exercised code path ---
and what I'm thinking is that they are flat out wrong.  At least for
testing system().  Are the results of GetExitCodeProcess() and pclose()
really defined differently?

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend