Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Fri, Jan 12, 2007 at 01:45:10AM +0100, Chris Mair wrote: I just wanted to mention that the latest release of OpenBSD i386 (4.0) is still broken too. So the ecpg-check failure would apply to (at least) to 3.8, 4.0, and likely 3.9. ok, but then we have some hosts in the buildfarm that run the updated versions like zebra and spoonbill. In this case we can't decide on the OS version number and cannot provide alternative files. Any idea except for actively replacing the offending line via sed from the regression script? Joachim ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Joachim Wieland wrote: On Fri, Jan 12, 2007 at 01:45:10AM +0100, Chris Mair wrote: I just wanted to mention that the latest release of OpenBSD i386 (4.0) is still broken too. So the ecpg-check failure would apply to (at least) to 3.8, 4.0, and likely 3.9. ok, but then we have some hosts in the buildfarm that run the updated versions like zebra and spoonbill. In this case we can't decide on the OS version number and cannot provide alternative files. Any idea except for actively replacing the offending line via sed from the regression script? that is incorrect - both zebra(4.0) and spoonbill(3.9) are not affected by this bug - the libc issue in question only affects i386 and m68k with OpenBSD 4.0 and older. So neither Spoonbill (Sparc64) nor Zebra (amd64/x86_64) ever had that issue. Stefan ---(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] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Fri, 12 Jan 2007 10:09:34 +0100 Joachim Wieland [EMAIL PROTECTED] wrote: On Fri, Jan 12, 2007 at 09:29:36AM +0100, Stefan Kaltenbrunner wrote: ok, but then we have some hosts in the buildfarm that run the updated versions like zebra and spoonbill. In this case we can't decide on the OS version number and cannot provide alternative files. Any idea except for actively replacing the offending line via sed from the regression script? that is incorrect - both zebra(4.0) and spoonbill(3.9) are not affected by this bug - the libc issue in question only affects i386 and m68k with OpenBSD 4.0 and older. So neither Spoonbill (Sparc64) nor Zebra (amd64/x86_64) ever had that issue. Okay, so it also depends on the platform... In this case I suggest to add the special expected/ files only for guppy, i.e. only for i386-unknown-openbsd3.8. If we get another i386 or m68k host that runs one of the affected systems, we have to update the check. However, if guppy got upgraded to 4.0 we'd have the problem that both guppy and emu would return i386-unknown-openbsd4.0 (while emu is running 4.0-current and hence is not affected)... Attached patch enables the special expected files only for i386-unknown-openbsd3.8. Ok, I feel sorry, guppy is causing so much trouble :| I guess then I'm going to upgrade her only when 4.1-stable comes out (in May). (i keep having this idea that if we all run current/unstable versions of our OSes we might overlook other issues ...) Bye, Chris. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Fri, Jan 12, 2007 at 01:20:15AM +0100, Joachim Wieland wrote: Attached is a patch to get guppy green again (hopefully). Applied. 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 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] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Joachim Wieland [EMAIL PROTECTED] writes: Attached patch enables the special expected files only for i386-unknown-openbsd3.8. This seems the wrong approach; we do not have anywhere near that good a handle on which platforms have this behavior. I'd vote for treating it like a locale difference, ie, just accept either result on any platform. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Attached is a patch to get guppy green again (hopefully). The two new files go into src/interfaces/ecpg/test/expected Hi, I just wanted to mention that the latest release of OpenBSD i386 (4.0) is still broken too. So the ecpg-check failure would apply to (at least) to 3.8, 4.0, and likely 3.9. Bye :) Chris. PS: OpenBSD 4.0 current is fixed, but I was reluctant to update to current... ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Tom Lane wrote: Joachim Wieland [EMAIL PROTECTED] writes: Attached patch enables the special expected files only for i386-unknown-openbsd3.8. This seems the wrong approach; we do not have anywhere near that good a handle on which platforms have this behavior. I'd vote for treating it like a locale difference, ie, just accept either result on any platform. well the information I from the openbsd-developers is that only i386 and m68k are affected(and fixed in http://archives.neohapsis.com/archives/openbsd/cvs/2006-10/0006.html but only for -current). If you are concerned about other OSes however ... Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Joachim Wieland wrote: On Thu, Jan 11, 2007 at 01:15:56PM +0100, Magnus Hagander wrote: Can't comment on that one, since I just noticed it existed. How similar was this one to the standard regression tests? Those were moved into a C executable so they'd run on a Windows system without a shell, could the same be done relatively easilyi with this one? (Obviously we can't run the ecpg regression tests on msvc builds now - oops, didn't know those had their own script) The ecpg regression tests came in when you started to rewrite the old regression script. Actually we exchanged some e-mails about this topic at that time :-) Crappy memory then :-) I don't even recall it now that you mention it ;-) Too bad you didn't have a ready-made solution... //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Thu, Jan 11, 2007 at 08:41:24AM +0100, Michael Meskes wrote: While I'm whining ... we really need some support in the ecpg regression tests for platform-specific diffs, so that the consistent ECPG-check failures in buildfarm can go away. Hmm, I thought there was. Joachim, could you comment? There are, see for example ecpg/test/expected/compat_informix-dec_test-MinGW32.stdout AFAIK there were no other platforms except for MinGW that need special treatment. On the buildfarm we have ecpg failures right now on: - osprey - guppy - clownfish osprey just seems to be out of diskspace. On guppy the ecpg checks trigger the OpenBSD bug that Michael and Stefan identfied here: http://archives.postgresql.org/pgsql-hackers/2006-09/msg00593.php Not sure what to do about it, we could diff it away to get it green but it would not solve the problem. What do you think? I will ask the maintainer of the box if he intends to update the operating system. If not, I'd propose to diff it away for the time being. Clownfish is the Solaris box where Stefan reported segmentation faults only some days ago. We need to look into this one. Joachim ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Thu, Jan 11, 2007 at 09:51:11AM +0100, Joachim Wieland wrote: There are, see for example ecpg/test/expected/compat_informix-dec_test-MinGW32.stdout AFAIK there were no other platforms except for MinGW that need special treatment. Talking about MinGW, do all MinGW systems return: Connection refused (0x274D/10061) if the connection is refused, or do the numbers differ? Or in other words, do we need the sed call in pg_regress.sh or could we do this with a arch specific expected file too? 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 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] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Thu, Jan 11, 2007 at 10:49:59AM +0100, Michael Meskes wrote: On Thu, Jan 11, 2007 at 09:51:11AM +0100, Joachim Wieland wrote: There are, see for example ecpg/test/expected/compat_informix-dec_test-MinGW32.stdout AFAIK there were no other platforms except for MinGW that need special treatment. Talking about MinGW, do all MinGW systems return: Connection refused (0x274D/10061) if the connection is refused, or do the numbers differ? It shuold be the same - 10061 is the win32 error code. 274D is just the hex version of the same one. Or in other words, do we need the sed call in pg_regress.sh or could we do this with a arch specific expected file too? Can't comment on that one, since I just noticed it existed. How similar was this one to the standard regression tests? Those were moved into a C executable so they'd run on a Windows system without a shell, could the same be done relatively easilyi with this one? (Obviously we can't run the ecpg regression tests on msvc builds now - oops, didn't know those had their own script) //Magnus ---(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] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Sat, Jan 06, 2007 at 01:37:03PM +0100, Joachim Wieland wrote: Attached is a patch that adds a --regression option to ecpg. I replaced the manual checking for long options (--version and --help) by a call to ... Applied. I also changed the regression handling in other places. Guys, please test and don't be suprised if something break on the buildfarm. So far it's only tested on my system. It works here. :-) 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 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] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Joachim Wieland [EMAIL PROTECTED] writes: On guppy the ecpg checks trigger the OpenBSD bug that Michael and Stefan identfied here: http://archives.postgresql.org/pgsql-hackers/2006-09/msg00593.php Not sure what to do about it, we could diff it away to get it green but it would not solve the problem. It's not our problem to solve, so I'd vote for providing the alternate test file. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Thu, Jan 11, 2007 at 01:15:56PM +0100, Magnus Hagander wrote: Can't comment on that one, since I just noticed it existed. How similar was this one to the standard regression tests? Those were moved into a C executable so they'd run on a Windows system without a shell, could the same be done relatively easilyi with this one? (Obviously we can't run the ecpg regression tests on msvc builds now - oops, didn't know those had their own script) The ecpg regression tests came in when you started to rewrite the old regression script. Actually we exchanged some e-mails about this topic at that time :-) To get ecpg regression tests on msvc we could either convert the script to a .c file as well or think about a general regression test library that could be used by contrib or pgfoundry modules as well. Does anybody have pointers to the archives on this topic? Joachim ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Bruce Momjian [EMAIL PROTECTED] writes: Joachim Wieland wrote: Attached is a patch that adds a --regression option to ecpg. I have added a checklist item to update the ecpg regression output for major release bumps. I think that is the easiest solution at this point. While I can't say whether Joachim's patch is the cleanest way, surely we will not condemn ourselves to fixing this manually in every future release cycle. While I'm whining ... we really need some support in the ecpg regression tests for platform-specific diffs, so that the consistent ECPG-check failures in buildfarm can go away. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Wed, Jan 10, 2007 at 11:31:41PM -0500, Tom Lane wrote: While I can't say whether Joachim's patch is the cleanest way, surely we will not condemn ourselves to fixing this manually in every future release cycle. I couldn't agree more. The reason why I haven't committed Joachim's patch yet is that I'd like to bring all regression specific changes to one place. Right now we have one change to the log file before diff'ing, one environment variable set and a command line option. The easiest way would be to just change the log files. This guarantees that regression ecpg behaves exactly as the productive one. However, this might get ugly quickly. I will have a closer look at this as soon as my time permits. While I'm whining ... we really need some support in the ecpg regression tests for platform-specific diffs, so that the consistent ECPG-check failures in buildfarm can go away. Hmm, I thought there was. Joachim, could you comment? 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
On Wed, Jan 10, 2007 at 11:50:10PM -0500, Bruce Momjian wrote: I think we need to hear from Michael wither that version number in the C file is needed. It certainly is not for regression testing. However, I think it should be there for production use so people know how they created those .c files they have around. 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] [COMMITTERS] pgsql: Stamp major release 8.3.0, and increment
Bruce Momjian wrote: Log Message: --- Stamp major release 8.3.0, and increment library version numbers. this commit broke the buildfarm(ECPG-checks): http://www.pgbuildfarm.org/cgi-bin/show_status.pl Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0, and
Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Log Message: --- Stamp major release 8.3.0, and increment library version numbers. this commit broke the buildfarm(ECPG-checks): http://www.pgbuildfarm.org/cgi-bin/show_status.pl Thanks, fixed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0, and
Bruce Momjian [EMAIL PROTECTED] writes: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Stamp major release 8.3.0, and increment library version numbers. this commit broke the buildfarm(ECPG-checks): http://www.pgbuildfarm.org/cgi-bin/show_status.pl Thanks, fixed. The idea of having to do this at every version number bump is pretty unappetizing. Shouldn't we fix things so that the version number doesn't appear in the ecpg regression files? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Stamp major release 8.3.0, and increment library version numbers. this commit broke the buildfarm(ECPG-checks): http://www.pgbuildfarm.org/cgi-bin/show_status.pl Thanks, fixed. The idea of having to do this at every version number bump is pretty unappetizing. Shouldn't we fix things so that the version number doesn't appear in the ecpg regression files? It would be nice, yea, or we can stip out that line when doing the diff. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
