Thread: Re: [COMMITTERS] pgsql: Stamp major release 8.3.0,
Joachim Wieland wrote: > On Fri, Jan 05, 2007 at 05:55:45PM -0500, Bruce Momjian wrote: > > > 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. > > 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 > getopt_long(). Unfortunately I don't have access to a platform that does not > support getopt_long, so maybe there is something missing for those platforms > (including for Windows maybe). > > The other patch is against the expected/ directory to replace the version > number with a fixed string. 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. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> 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
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: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
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
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 (0x0000274D/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: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
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 (0x0000274D/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
> It shuold be the same - 10061 is the win32 error code. 274D is just the > hex version of the same one. Okay, changed this. Please test if you have a MinGW setup. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Joachim Wieland <joe@mcknight.de> 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
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
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
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
On Fri, 12 Jan 2007 10:09:34 +0100 Joachim Wieland <joe@mcknight.de> 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.
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: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Joachim Wieland <joe@mcknight.de> 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
> 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...
Tom Lane wrote: > Joachim Wieland <joe@mcknight.de> 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
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