Re: [HACKERS] ECPG regression tests generating warnings
On Sun, Jan 12, 2014 at 08:28:57AM -0800, Kevin Grittner wrote: desc.pgc:55: WARNING: descriptor outdesc does not exist desc.pgc:86: WARNING: descriptor outdesc does not exist Thanks, I didn't notice, fixed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ECPG regression tests generating warnings
Since 192b4aacad45c16a8a9341644479125977366dab my `make check-world` runs are generating these two warnings: desc.pgc:55: WARNING: descriptor outdesc does not exist desc.pgc:86: WARNING: descriptor outdesc does not exist The referenced file is in the src/interfaces/ecpg/test/sql/ directory and was modified by the above-mentioned commit. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ECPG regression tests need .gitignore update?
After running make installcheck-world, git status shows a bunch of stuff that looks like this: # src/interfaces/ecpg/test/sql/desc.dSYM/ # src/interfaces/ecpg/test/sql/describe.dSYM/ # src/interfaces/ecpg/test/sql/dynalloc.dSYM/ # src/interfaces/ecpg/test/sql/dynalloc2.dSYM/ # src/interfaces/ecpg/test/sql/dyntest.dSYM/ -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG regression tests need .gitignore update?
Robert Haas robertmh...@gmail.com writes: After running make installcheck-world, git status shows a bunch of stuff that looks like this: # src/interfaces/ecpg/test/sql/desc.dSYM/ # src/interfaces/ecpg/test/sql/describe.dSYM/ # src/interfaces/ecpg/test/sql/dynalloc.dSYM/ # src/interfaces/ecpg/test/sql/dynalloc2.dSYM/ # src/interfaces/ecpg/test/sql/dyntest.dSYM/ Mac user eh? This seems like a build-process bug, not a .gitignore oversight. Those shouldn't be there at all (and I notice make clean doesn't get rid of them). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG regression tests need .gitignore update?
On Tue, Oct 19, 2010 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: After running make installcheck-world, git status shows a bunch of stuff that looks like this: # src/interfaces/ecpg/test/sql/desc.dSYM/ # src/interfaces/ecpg/test/sql/describe.dSYM/ # src/interfaces/ecpg/test/sql/dynalloc.dSYM/ # src/interfaces/ecpg/test/sql/dynalloc2.dSYM/ # src/interfaces/ecpg/test/sql/dyntest.dSYM/ Mac user eh? Blame dpage. This seems like a build-process bug, not a .gitignore oversight. Those shouldn't be there at all (and I notice make clean doesn't get rid of them). I don't even know what they are. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG regression tests need .gitignore update?
Robert Haas robertmh...@gmail.com writes: On Tue, Oct 19, 2010 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: This seems like a build-process bug, not a .gitignore oversight. Those shouldn't be there at all (and I notice make clean doesn't get rid of them). I don't even know what they are. Outboard debug symbols. Some googling just turned up this interesting comment: Interesting quirk: on MacOS 10.6.2, if you include a source file in the 'link' line, then the dsymutil program is run to generate the .dSYM information; if you only link object files and libraries, then the dsymutil program is not run so the .dSYM information is not generated. You can validate this with the '-v' option to GCC which shows the programs executed by 'gcc'. So maybe we can get rid of it by not using the shortcut of skipping creation of a .o file. Off to try that ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG regression tests
On Tue, Oct 09, 2007 at 05:44:22PM -0400, Andrew Dunstan wrote: Andrew Dunstan wrote: Magnus Hagander wrote: (Hint: if you don't put the PlatformSDK directories first in the INCLUDE and LIB lists bad and inexplicable things can happen.) Pick up the latest version of run_build.pl in CVS if you want to run this in your buildfarm animal now. A release will be forthcoming very soon. I put it in, but it doesn't work. It works when running ecpg tests manual, but from run_build I get: http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=skylarkdt=2007-10-09%20090814stg=ecpg-check which seems similar to what you had before. How did you fix that one? Is that the one requiring a reorder? Yes. compare its build_env INCLUDE and LIB and possibly PATH values with those of red_bat: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=red_batdt=2007-10-09%2004:30:04 BTW, following some advice I found on the net those PlatformSDK directories were copied manually from the SDK install, back when I installed MSVC. You also appear to have simply a configuration bug - there is a missing semicolon or two in: LIB' = 'D:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\ATLMFC\\LIB;D:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\LIBD:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib;D:\\Program Files (x86)\\Microsoft Visual Studio 8\\SDK\\v2.0\\libD:\\Program Files (x86)\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\Lib\\;C:\\Program Files\\SQLXML 4.0\\bin\\', Gah. That was it, I had . instead of , in the config file :-( Fixing that made the ecpg regression etsts pass, didn't have to reorder or change anything at all. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ECPG regression tests
On Sat, Oct 06, 2007 at 11:50:39PM -0400, Andrew Dunstan wrote: Andrew Dunstan wrote: Magnus Hagander wrote: Bingo. With that, all the ECPG regression tests now pass on MSVC builds. Andrew - please enable it for the buildfarm :-) Yes, when I have had a chance to test it. Might be a day or so. I finally managed to get this working after much wailing and gnashing of teeth and rending of hair. (Hint: if you don't put the PlatformSDK directories first in the INCLUDE and LIB lists bad and inexplicable things can happen.) Pick up the latest version of run_build.pl in CVS if you want to run this in your buildfarm animal now. A release will be forthcoming very soon. I put it in, but it doesn't work. It works when running ecpg tests manual, but from run_build I get: http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=skylarkdt=2007-10-09%20090814stg=ecpg-check which seems similar to what you had before. How did you fix that one? Is that the one requiring a reorder? //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ECPG regression tests
Magnus Hagander wrote: (Hint: if you don't put the PlatformSDK directories first in the INCLUDE and LIB lists bad and inexplicable things can happen.) Pick up the latest version of run_build.pl in CVS if you want to run this in your buildfarm animal now. A release will be forthcoming very soon. I put it in, but it doesn't work. It works when running ecpg tests manual, but from run_build I get: http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=skylarkdt=2007-10-09%20090814stg=ecpg-check which seems similar to what you had before. How did you fix that one? Is that the one requiring a reorder? Yes. compare its build_env INCLUDE and LIB and possibly PATH values with those of red_bat: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=red_batdt=2007-10-09%2004:30:04 BTW, following some advice I found on the net those PlatformSDK directories were copied manually from the SDK install, back when I installed MSVC. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ECPG regression tests
Andrew Dunstan wrote: Magnus Hagander wrote: (Hint: if you don't put the PlatformSDK directories first in the INCLUDE and LIB lists bad and inexplicable things can happen.) Pick up the latest version of run_build.pl in CVS if you want to run this in your buildfarm animal now. A release will be forthcoming very soon. I put it in, but it doesn't work. It works when running ecpg tests manual, but from run_build I get: http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=skylarkdt=2007-10-09%20090814stg=ecpg-check which seems similar to what you had before. How did you fix that one? Is that the one requiring a reorder? Yes. compare its build_env INCLUDE and LIB and possibly PATH values with those of red_bat: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=red_batdt=2007-10-09%2004:30:04 BTW, following some advice I found on the net those PlatformSDK directories were copied manually from the SDK install, back when I installed MSVC. You also appear to have simply a configuration bug - there is a missing semicolon or two in: LIB' = 'D:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\ATLMFC\\LIB;D:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\LIBD:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib;D:\\Program Files (x86)\\Microsoft Visual Studio 8\\SDK\\v2.0\\libD:\\Program Files (x86)\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\Lib\\;C:\\Program Files\\SQLXML 4.0\\bin\\', cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ECPG regression tests
Andrew Dunstan wrote: Magnus Hagander wrote: Bingo. With that, all the ECPG regression tests now pass on MSVC builds. Andrew - please enable it for the buildfarm :-) Yes, when I have had a chance to test it. Might be a day or so. I finally managed to get this working after much wailing and gnashing of teeth and rending of hair. (Hint: if you don't put the PlatformSDK directories first in the INCLUDE and LIB lists bad and inexplicable things can happen.) Pick up the latest version of run_build.pl in CVS if you want to run this in your buildfarm animal now. A release will be forthcoming very soon. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] ECPG regression tests
Getting much further now - now they all build :-) But I'm getting a couple of failures in autoprep and oldexec. Diffs attached. Pointers? //Magnus *** ./expected/preproc-autoprep.stderr 2007-10-01 10:57:37.532045600 +0200 --- ./results/preproc-autoprep.stderr 2007-10-03 13:53:13.898609200 +0200 *** *** 2,44 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGconnect: opening database regress1 on DEFAULT port DEFAULT [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGauto_prepare line 19: stmt not in cache; inserting - [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGprepare line 19: NAME: ecpg1 QUERY: create table T ( Item1 int , Item2 int ) - [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 19: QUERY: create table T ( Item1 int , Item2 int ) with 0 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 19: using PQexecPrepared for create table T ( Item1 int , Item2 int ) [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 19 Ok: CREATE TABLE [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGauto_prepare line 21: stmt not in cache; inserting - [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGprepare line 21: NAME: ecpg2 QUERY: insert into T values ( 1 , null ) - [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 21: QUERY: insert into T values ( 1 , null ) with 0 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 21: using PQexecPrepared for insert into T values ( 1 , null ) [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 21 Ok: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGauto_prepare line 22: stmt not in cache; inserting - [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGprepare line 22: NAME: ecpg3 QUERY: insert into T values ( 1 , $1 ) - [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 22: QUERY: insert into T values ( 1 , $1 ) with 1 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 22: using PQexecPrepared for insert into T values ( 1 , $1 ) [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 22: parameter 1 = 1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 22 Ok: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGauto_prepare line 24: stmt found in cache, entry 6248 - [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 24: QUERY: insert into T values ( 1 , $1 ) with 1 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 24: using PQexecPrepared for insert into T values ( 1 , $1 ) [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 24: parameter 1 = 2 [NO_PID]: sqlca: code: 0, state: 0 --- 2,30 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGconnect: opening database regress1 on DEFAULT port DEFAULT [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 19: QUERY: create table T ( Item1 int , Item2 int ) with 0 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 19: using PQexec [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 19 Ok: CREATE TABLE [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 21: QUERY: insert into T values ( 1 , null ) with 0 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 21: using PQexec [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 21 Ok: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 22: QUERY: insert into T values ( 1 , $1 ) with 1 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 22: using PQexecParams [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 22: parameter 1 = 1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 22 Ok: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 24: QUERY: insert into T values ( 1 , $1 ) with 1 parameter on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGexecute line 24: using PQexecParams [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 24: parameter 1 = 2 [NO_PID]: sqlca: code: 0, state: 0 *** *** 52,64 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 26 Ok: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGauto_prepare line 28: stmt not in cache; inserting - [NO_PID]: sqlca: code: 0, state: 0 - [NO_PID]: ECPGprepare line 28: NAME: ecpg4 QUERY: select Item2 from T order by Item2 nulls last - [NO_PID]: sqlca:
Re: [HACKERS] ECPG regression tests
On Wed, Oct 03, 2007 at 01:54:50PM +0200, Magnus Hagander wrote: Getting much further now - now they all build :-) But I'm getting a couple of failures in autoprep and oldexec. Diffs attached. Pointers? Looks like we're almost there. oldexec needs the additional option -r questionmarks to ecpg. Here's the line from the normal Makefile: $(ECPG) -r questionmarks -o $@ -I$(srcdir) $ autoprep also needs an additional parameter. It's -r prepare. And again, here's the line: $(ECPG) -r prepare -o $@ -I$(srcdir) $ Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ECPG regression tests
On Wed, Oct 03, 2007 at 02:12:50PM +0200, Michael Meskes wrote: On Wed, Oct 03, 2007 at 01:54:50PM +0200, Magnus Hagander wrote: Getting much further now - now they all build :-) But I'm getting a couple of failures in autoprep and oldexec. Diffs attached. Pointers? Looks like we're almost there. oldexec needs the additional option -r questionmarks to ecpg. Here's the line from the normal Makefile: $(ECPG) -r questionmarks -o $@ -I$(srcdir) $ autoprep also needs an additional parameter. It's -r prepare. And again, here's the line: $(ECPG) -r prepare -o $@ -I$(srcdir) $ Bingo. With that, all the ECPG regression tests now pass on MSVC builds. Andrew - please enable it for the buildfarm :-) //Magnus ---(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] ECPG regression tests
On Wed, Oct 03, 2007 at 02:34:59PM +0200, Magnus Hagander wrote: With that, all the ECPG regression tests now pass on MSVC builds. Great! Thanks a lot for your help Magnus. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ECPG regression tests
Magnus Hagander wrote: Bingo. With that, all the ECPG regression tests now pass on MSVC builds. Andrew - please enable it for the buildfarm :-) Yes, when I have had a chance to test it. Might be a day or so. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ECPG regression tests expected files
On Wed, Mar 28, 2007 at 07:30:21PM +0200, Magnus Hagander wrote: If you want to pick one early, please look at the one about the thread regression tests not appearing to run at all. I'd like to have that confirmed before I try to dig into how to fix it - in case it's not actually broken, and it's just me who's doing something wrong... I just committed some stuff including your patch and a fix to the regression test problem. At least it works on my system. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] ECPG regression tests expected files
On Thu, Mar 29, 2007 at 02:04:48PM +0200, Michael Meskes wrote: On Wed, Mar 28, 2007 at 07:30:21PM +0200, Magnus Hagander wrote: If you want to pick one early, please look at the one about the thread regression tests not appearing to run at all. I'd like to have that confirmed before I try to dig into how to fix it - in case it's not actually broken, and it's just me who's doing something wrong... I just committed some stuff including your patch and a fix to the regression test problem. At least it works on my system. Thanks. Passes the regression tests on win32 with the native threading. I've updated and committed updates to the thread regression tests to have them use the native threading as well. This removes the final requirement on pthreads on win32, so that's one more non-standard build depdendency no longer needed. Yay! //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] ECPG regression tests expected files
If I change the code in one of the ecpg regression tests (porting tests as well to non-pthread win32), am I supposed to manually change the .c files in the expected directory? Or is ther some other process for it? //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] ECPG regression tests expected files
On Wed, Mar 28, 2007 at 06:13:03PM +0200, Magnus Hagander wrote: If I change the code in one of the ecpg regression tests (porting tests as well to non-pthread win32), am I supposed to manually change the .c files in the expected directory? Or is ther some other process for it? Just run the test, check whether it's okay and then replace the expected .c file with yours. Please change what you need for win32. I will have a look at the changes on Linux as soon as I find time. The other thread related emails are still in my inbox. So the same holds for those. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ECPG regression tests expected files
Michael Meskes wrote: On Wed, Mar 28, 2007 at 06:13:03PM +0200, Magnus Hagander wrote: If I change the code in one of the ecpg regression tests (porting tests as well to non-pthread win32), am I supposed to manually change the .c files in the expected directory? Or is ther some other process for it? Just run the test, check whether it's okay and then replace the expected .c file with yours. Ok. Please change what you need for win32. I will have a look at the changes on Linux as soon as I find time. The other thread related emails are still in my inbox. So the same holds for those. :-) Ok. Will do. If you want to pick one early, please look at the one about the thread regression tests not appearing to run at all. I'd like to have that confirmed before I try to dig into how to fix it - in case it's not actually broken, and it's just me who's doing something wrong... //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ECPG regression tests seem rather fundamentally broken
Tom Lane wrote: AFAICT, every buildfarm machine that runs ecpg tests has been failing since Peter's patch here: http://archives.postgresql.org/pgsql-committers/2007-01/msg00241.php Now it looks to me like Peter was simply wrong: we do need to include libpq because libecpg depends on it. However, I tried reverting the change and things still did not work. The reason is that the test programs are built with relative paths to libpq that look like ../../../../../src/interfaces/libpq/libpq.sl.5 This is a symptom specific to HP-UX, which hardcodes the link-time library path into the output. The ECPG test probably never worked there. and then executed one level up from where they were built, causing the relative path to be no good. I suspect the only reason it has been appearing to work for awhile is that people had usable copies of libpq and perhaps libecpg installed in system-standard library directories. Take away those preinstalled libs, or render them version-incompatible, and the ecpg tests stop working. I don't have any matching preinstalled libraries anywhere and I verified with ldd that it seems to look in the expected places for both libraries, and indeed the tests pass for me, so I don't know what's going on. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] ECPG regression tests seem rather fundamentally broken
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: ... However, I tried reverting the change and things still did not work. The reason is that the test programs are built with relative paths to libpq that look like ../../../../../src/interfaces/libpq/libpq.sl.5 This is a symptom specific to HP-UX, which hardcodes the link-time library path into the output. The ECPG test probably never worked there. Au contraire, it did work last time I tried (which I must admit was a few months ago, so I cannot be sure just when we broke it). And anyway, how would you expect it to magically work differently on some other platform, for a library that is neither present in the system's standard search path, the rpath (which we failed to provide anyway), nor the build-time-relative path? I'm not quite sure what other plan the dynamic linker should follow. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] ECPG regression tests seem rather fundamentally broken
AFAICT, every buildfarm machine that runs ecpg tests has been failing since Peter's patch here: http://archives.postgresql.org/pgsql-committers/2007-01/msg00241.php Now it looks to me like Peter was simply wrong: we do need to include libpq because libecpg depends on it. However, I tried reverting the change and things still did not work. The reason is that the test programs are built with relative paths to libpq that look like ../../../../../src/interfaces/libpq/libpq.sl.5 and then executed one level up from where they were built, causing the relative path to be no good. I suspect the only reason it has been appearing to work for awhile is that people had usable copies of libpq and perhaps libecpg installed in system-standard library directories. Take away those preinstalled libs, or render them version-incompatible, and the ecpg tests stop working. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
