Обсуждение: Re: [PATCHES] Patch to fix plpython on OS X
"Jim C. Nasby" <decibel@decibel.org> writes: > On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote: >> "Jim C. Nasby" <decibel@decibel.org> writes: >>> Attached is a plpython_error_1.out file that will fix cuckoo. >> >> What is the reason for the difference in the error message spelling >> in the first place? Is this a Python version thing (and if so, >> which version is newer --- that should have pride of place as >> plpython_error.out I should think)? Or is there some other reason >> that we need to understand more closely instead of just slapping on >> a band-aid? > I don't think it's a version issue; cuckoo is at 2.4, platypus used to > be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but > platypus kept working. Hmm ... if it's *not* a version thing then I really do want to know what's causing it. Anyone have an idea why this machine is saying '\u80' where everyone else's python says u'\x80' ? *** ./expected/plpython_error.out Mon Jul 18 22:06:49 2005 --- ./results/plpython_error.out Mon Jul 18 23:53:30 2005 *************** *** 24,38 **** -- SELECT unicode_return_error(); ERROR: plpython: function "unicode_return_error" could not create return value ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128) INSERT INTO unicode_test (testvalue) VALUES ('test'); ERROR: plpython: function "unicode_trigger_error" could not modify tuple ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128) SELECT unicode_plan_error1(); WARNING: plpython: in function unicode_plan_error1: DETAIL: plpy.Error: Unknown error in PLy_spi_execute_plan ERROR: plpython: function "unicode_plan_error1" could not execute plan ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128) SELECT unicode_plan_error2(); ERROR: plpython: function "unicode_plan_error2" could not execute plan ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128) --- 24,38 ---- -- SELECT unicode_return_error(); ERROR: plpython: function "unicode_return_error" could not create return value ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character '\u80' in position 0: ordinal not in range(128) INSERT INTO unicode_test (testvalue) VALUES ('test'); ERROR: plpython: function "unicode_trigger_error" could not modify tuple ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character '\u80' in position 0: ordinal not in range(128) SELECT unicode_plan_error1(); WARNING: plpython: in function unicode_plan_error1: DETAIL: plpy.Error: Unknown error in PLy_spi_execute_plan ERROR: plpython: function "unicode_plan_error1" could not execute plan ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character '\u80' in position 0: ordinal not in range(128) SELECT unicode_plan_error2(); ERROR: plpython: function "unicode_plan_error2" could not execute plan ! DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character '\u80' in position 0: ordinal not in range(128) regards, tom lane
On Tue, Jul 19, 2005 at 02:48:52PM -0400, Tom Lane wrote: > "Jim C. Nasby" <decibel@decibel.org> writes: > > I don't think it's a version issue; cuckoo is at 2.4, platypus used to > > be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but > > platypus kept working. > > Hmm ... if it's *not* a version thing then I really do want to know > what's causing it. Anyone have an idea why this machine is saying > '\u80' where everyone else's python says u'\x80' ? Is it possible that plpython.so is linked against an old version of libpython? I see that the error message changed a few years ago: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/exceptions.c?r1=1.44&r2=1.45 http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/exceptions.c?r1=1.45&r2=1.46 As I recall, Python must be configured with --enable-shared or you don't get a shared version of libpython, so if you installed a new Python but not a new version of libpython.*.so, then plpython.so might be linked against an old version. Does this machine have ldd or the equivalent? If so, can you compare "ldd /path/to/python" and "ldd /path/to/plpython.so"? -- Michael Fuhr http://www.fuhr.org/~mfuhr/
On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote: > On Tue, Jul 19, 2005 at 02:48:52PM -0400, Tom Lane wrote: > > "Jim C. Nasby" <decibel@decibel.org> writes: > > > I don't think it's a version issue; cuckoo is at 2.4, platypus used to > > > be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but > > > platypus kept working. > > > > Hmm ... if it's *not* a version thing then I really do want to know > > what's causing it. Anyone have an idea why this machine is saying > > '\u80' where everyone else's python says u'\x80' ? > > Is it possible that plpython.so is linked against an old version > of libpython? I see that the error message changed a few years ago: > > http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/exceptions.c?r1=1.44&r2=1.45 > http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/exceptions.c?r1=1.45&r2=1.46 > > As I recall, Python must be configured with --enable-shared or you > don't get a shared version of libpython, so if you installed a new > Python but not a new version of libpython.*.so, then plpython.so > might be linked against an old version. > > Does this machine have ldd or the equivalent? If so, can you compare > "ldd /path/to/python" and "ldd /path/to/plpython.so"? Oddly, no, it doesn't seem to have ldd. And the buildfarm script seems to clean everything up even in the pgsqlkeep directories; or at least I couldn't find a plpython.so laying around. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Tue, Jul 19, 2005 at 03:11:35PM -0500, Jim C. Nasby wrote: > On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote: > > Does this machine have ldd or the equivalent? If so, can you compare > > "ldd /path/to/python" and "ldd /path/to/plpython.so"? > > Oddly, no, it doesn't seem to have ldd. And the buildfarm script seems > to clean everything up even in the pgsqlkeep directories; or at least I > couldn't find a plpython.so laying around. [googles] "otool -L" appears to be the Darwin equivalent of ldd. If you can manage to find a plpython.so then it would be interesting to see which libpython it's linked against. Can you search the system for all files named libpython* and post what you find? -- Michael Fuhr http://www.fuhr.org/~mfuhr/
Jim C. Nasby wrote: >And the buildfarm script seems >to clean everything up even in the pgsqlkeep directories; or at least I >couldn't find a plpython.so laying around. > > Nothing should be removed. If you are using the experimental code I recently gave you all bets are off, but under normal circumstances if you run with --keepall then your plpython.so should be there. cheers andrew
On Tue, Jul 19, 2005 at 02:42:07PM -0600, Michael Fuhr wrote: > On Tue, Jul 19, 2005 at 03:11:35PM -0500, Jim C. Nasby wrote: > > On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote: > > > Does this machine have ldd or the equivalent? If so, can you compare > > > "ldd /path/to/python" and "ldd /path/to/plpython.so"? > > > > Oddly, no, it doesn't seem to have ldd. And the buildfarm script seems > > to clean everything up even in the pgsqlkeep directories; or at least I > > couldn't find a plpython.so laying around. > > [googles] > > "otool -L" appears to be the Darwin equivalent of ldd. If you can > manage to find a plpython.so then it would be interesting to see > which libpython it's linked against. I'm going to run a build with the non-experimental version of run_build.pl and see if I'll have some files left then. > Can you search the system for all files named libpython* and post > what you find? buildfar@phonebook.1[16:42]~:11%locate libpython /Applications/NeoOfficeJ.app/Contents/MacOS/libpython.dylib /Applications/NeoOfficeJ.app/Contents/MacOS/libpython2.2.dylib /Applications/NeoOfficeJ.app/Contents/MacOS/libpython2.dylib /Applications/OpenOffice.org1.1.2/program/libpython.dylib /Applications/OpenOffice.org1.1.2/program/libpython2.2.dylib /Applications/OpenOffice.org1.1.2/program/libpython2.dylib /opt/local/lib/libpython2.4.dylib /opt/local/lib/python2.4/config/libpython2.4.a /opt/local/var/db/dports/software/python24/2.4_3/opt/local/lib/libpython2.4.dylib /opt/local/var/db/dports/software/python24/2.4_3/opt/local/lib/python2.4/config/libpython2.4.a buildfar@phonebook.1[16:42]~:12% -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Tue, Jul 19, 2005 at 04:51:03PM -0500, Jim C. Nasby wrote: > > Can you search the system for all files named libpython* and post > > what you find? > > buildfar@phonebook.1[16:42]~:11%locate libpython > /Applications/NeoOfficeJ.app/Contents/MacOS/libpython.dylib > /Applications/NeoOfficeJ.app/Contents/MacOS/libpython2.2.dylib > /Applications/NeoOfficeJ.app/Contents/MacOS/libpython2.dylib > /Applications/OpenOffice.org1.1.2/program/libpython.dylib > /Applications/OpenOffice.org1.1.2/program/libpython2.2.dylib > /Applications/OpenOffice.org1.1.2/program/libpython2.dylib > /opt/local/lib/libpython2.4.dylib > /opt/local/lib/python2.4/config/libpython2.4.a > /opt/local/var/db/dports/software/python24/2.4_3/opt/local/lib/libpython2.4.dylib > /opt/local/var/db/dports/software/python24/2.4_3/opt/local/lib/python2.4/config/libpython2.4.a > buildfar@phonebook.1[16:42]~:12% buildfar@phonebook.1[18:00]~/buildfarm/HEAD/pgsqlkeep.1121809875/src/pl/plpython:41%otool -L libplpython.0.0.so libplpython.0.0.so: /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3) buildfar@phonebook.1[18:00]~/buildfarm/HEAD/pgsqlkeep.1121809875/src/pl/plpython:42% buildfar@phonebook.1[18:01]~/buildfarm/HEAD/lastrun-logs:12%grep -i python configure.log make.log configure.log:checking whether to build Python modules... yes configure.log:checking for python... /opt/local/bin/python configure.log:checking for Python distutils module... yes configure.log:checking Python configuration directory... /opt/local/lib/python2.4/config configure.log:checking how to link an embedded Python application... -L/opt/local/lib/python2.4/config -lpython2.4 -ldl make.log:ccache gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g-DFRONTEND -I../../../src/interfaces/libpq -DVAL_CONFIGURE="\"'--with-includes=/opt/local/include' '--with-libraries=/opt/local/lib''--enable-cassert' '--enable-debug' '--enable-integer-datetimes' '--with-perl' '--with-python''--with-tcl' '--with-openssl' '--enable-depend' '--enable-nls' '--prefix=/Users/buildfarm/buildfarm/HEAD/inst''--with-pgport=5678' 'CC=ccache gcc'\"" -I../../../src/include -I/opt/local/include -c -o pg_config.o pg_config.c -MMD make.log:ccache gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g -I. -I/opt/local/include/python2.4 -I../../../src/include -I/opt/local/include -c -o plpython.o plpython.c -MMD make.log:In file included from /opt/local/include/python2.4/Python.h:77, make.log: from plpython.c:37: make.log:/opt/local/include/python2.4/objimpl.h:255: warning: use of `long double' type; its size may change in a futurerelease make.log:/opt/local/include/python2.4/objimpl.h:255: warning: (Long double usage is reported only once for each file. make.log:/opt/local/include/python2.4/objimpl.h:255: warning: To disable this warning, use -Wno-long-double.) make.log:ar crs libplpython.a `lorder plpython.o | tsort` make.log:ranlib libplpython.a make.log:ccache gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g -bundle plpython.o -L../../../src/port -L/opt/local/lib -bundle_loader ../../../src/backend/postgres -framework Python -o libplpython.0.0.so make.log:rm -f libplpython.0.so make.log:ln -s libplpython.0.0.so libplpython.0.so make.log:rm -f libplpython.so make.log:ln -s libplpython.0.0.so libplpython.so buildfar@phonebook.1[18:02]~/buildfarm/HEAD/lastrun-logs:13% Neither /opt/local/lib/libpython2.4.dylib or /opt/local/lib/python2.4/config/libpython2.4.a reference the /System/Library python, so I have no idea how it's finding it's way to that... buildfar@phonebook.1[18:03]~/buildfarm/HEAD/lastrun-logs:13%otool -L /opt/local/lib/libpython2.4.dylib /opt/local/lib/libpython2.4.dylib: /opt/local/lib/libpython2.4.dylib (compatibility version 2.4.0, current version 2.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1) buildfar@phonebook.1[18:03]~/buildfarm/HEAD/lastrun-logs:14%otool -L /opt/local/lib/python2.4/config/libpython2.4.a Archive : /opt/local/lib/python2.4/config/libpython2.4.a /opt/local/lib/python2.4/config/libpython2.4.a(getbuildinfo.o): /opt/local/lib/python2.4/config/libpython2.4.a(acceler.o): /opt/local/lib/python2.4/config/libpython2.4.a(grammar1.o): /opt/local/lib/python2.4/config/libpython2.4.a(listnode.o): /opt/local/lib/python2.4/config/libpython2.4.a(node.o): /opt/local/lib/python2.4/config/libpython2.4.a(parser.o): /opt/local/lib/python2.4/config/libpython2.4.a(parsetok.o): /opt/local/lib/python2.4/config/libpython2.4.a(bitset.o): /opt/local/lib/python2.4/config/libpython2.4.a(metagrammar.o): /opt/local/lib/python2.4/config/libpython2.4.a(firstsets.o): /opt/local/lib/python2.4/config/libpython2.4.a(grammar.o): /opt/local/lib/python2.4/config/libpython2.4.a(pgen.o): /opt/local/lib/python2.4/config/libpython2.4.a(myreadline.o): /opt/local/lib/python2.4/config/libpython2.4.a(tokenizer.o): /opt/local/lib/python2.4/config/libpython2.4.a(abstract.o): /opt/local/lib/python2.4/config/libpython2.4.a(boolobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(bufferobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(cellobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(classobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(cobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(complexobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(descrobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(enumobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(genobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(fileobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(floatobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(frameobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(funcobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(intobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(iterobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(listobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(longobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(dictobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(methodobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(moduleobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(object.o): /opt/local/lib/python2.4/config/libpython2.4.a(obmalloc.o): /opt/local/lib/python2.4/config/libpython2.4.a(rangeobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(setobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(sliceobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(stringobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(structseq.o): /opt/local/lib/python2.4/config/libpython2.4.a(tupleobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(typeobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(weakrefobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(unicodeobject.o): /opt/local/lib/python2.4/config/libpython2.4.a(unicodectype.o): /opt/local/lib/python2.4/config/libpython2.4.a(bltinmodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(exceptions.o): /opt/local/lib/python2.4/config/libpython2.4.a(ceval.o): /opt/local/lib/python2.4/config/libpython2.4.a(compile.o): /opt/local/lib/python2.4/config/libpython2.4.a(codecs.o): /opt/local/lib/python2.4/config/libpython2.4.a(errors.o): /opt/local/lib/python2.4/config/libpython2.4.a(frozen.o): /opt/local/lib/python2.4/config/libpython2.4.a(frozenmain.o): /opt/local/lib/python2.4/config/libpython2.4.a(future.o): /opt/local/lib/python2.4/config/libpython2.4.a(getargs.o): /opt/local/lib/python2.4/config/libpython2.4.a(getcompiler.o): /opt/local/lib/python2.4/config/libpython2.4.a(getcopyright.o): /opt/local/lib/python2.4/config/libpython2.4.a(getmtime.o): /opt/local/lib/python2.4/config/libpython2.4.a(getplatform.o): /opt/local/lib/python2.4/config/libpython2.4.a(getversion.o): /opt/local/lib/python2.4/config/libpython2.4.a(graminit.o): /opt/local/lib/python2.4/config/libpython2.4.a(import.o): /opt/local/lib/python2.4/config/libpython2.4.a(importdl.o): /opt/local/lib/python2.4/config/libpython2.4.a(marshal.o): /opt/local/lib/python2.4/config/libpython2.4.a(modsupport.o): /opt/local/lib/python2.4/config/libpython2.4.a(mystrtoul.o): /opt/local/lib/python2.4/config/libpython2.4.a(mysnprintf.o): /opt/local/lib/python2.4/config/libpython2.4.a(pyfpe.o): /opt/local/lib/python2.4/config/libpython2.4.a(pystate.o): /opt/local/lib/python2.4/config/libpython2.4.a(pythonrun.o): /opt/local/lib/python2.4/config/libpython2.4.a(structmember.o): /opt/local/lib/python2.4/config/libpython2.4.a(symtable.o): /opt/local/lib/python2.4/config/libpython2.4.a(sysmodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(traceback.o): /opt/local/lib/python2.4/config/libpython2.4.a(getopt.o): /opt/local/lib/python2.4/config/libpython2.4.a(pystrtod.o): /opt/local/lib/python2.4/config/libpython2.4.a(dynload_next.o): /opt/local/lib/python2.4/config/libpython2.4.a(mactoolboxglue.o): /opt/local/lib/python2.4/config/libpython2.4.a(thread.o): /opt/local/lib/python2.4/config/libpython2.4.a(config.o): /opt/local/lib/python2.4/config/libpython2.4.a(getpath.o): /opt/local/lib/python2.4/config/libpython2.4.a(main.o): /opt/local/lib/python2.4/config/libpython2.4.a(gcmodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(threadmodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(signalmodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(posixmodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(errnomodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(_sre.o): /opt/local/lib/python2.4/config/libpython2.4.a(_codecsmodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(zipimport.o): /opt/local/lib/python2.4/config/libpython2.4.a(symtablemodule.o): /opt/local/lib/python2.4/config/libpython2.4.a(xxsubtype.o): buildfar@phonebook.1[18:04]~/buildfarm/HEAD/lastrun-logs:15% -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Tue, Jul 19, 2005 at 06:06:00PM -0500, Jim C. Nasby wrote: > buildfar@phonebook.1[18:00]~/buildfarm/HEAD/pgsqlkeep.1121809875/src/pl/plpython:41%otool -L libplpython.0.0.so > libplpython.0.0.so: > /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3) If that first object has something to do with Python 2.3 then we might have found the culprit. But how'd you get that? > configure.log:checking Python configuration directory... /opt/local/lib/python2.4/config > configure.log:checking how to link an embedded Python application... -L/opt/local/lib/python2.4/config -lpython2.4 -ldl The above looks reasonable. > make.log:ccache gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing-g -bundle plpython.o -L../../../src/port -L/opt/local/lib -bundle_loader ../../../src/backend/postgres-framework Python -o libplpython.0.0.so Hmmm...what's that "-framework Python" business? Looks mighty suspicious in light of the otool output. -- Michael Fuhr http://www.fuhr.org/~mfuhr/
On Tue, Jul 19, 2005 at 05:47:37PM -0600, Michael Fuhr wrote: > On Tue, Jul 19, 2005 at 06:06:00PM -0500, Jim C. Nasby wrote: > > buildfar@phonebook.1[18:00]~/buildfarm/HEAD/pgsqlkeep.1121809875/src/pl/plpython:41%otool -L libplpython.0.0.so > > libplpython.0.0.so: > > /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version2.3.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3) > > If that first object has something to do with Python 2.3 then we > might have found the culprit. But how'd you get that? No idea at all. Is there some way to find out from how it was built? > > configure.log:checking Python configuration directory... /opt/local/lib/python2.4/config > > configure.log:checking how to link an embedded Python application... -L/opt/local/lib/python2.4/config -lpython2.4 -ldl > > The above looks reasonable. > > > make.log:ccache gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing-g -bundle plpython.o -L../../../src/port -L/opt/local/lib -bundle_loader ../../../src/backend/postgres-framework Python -o libplpython.0.0.so > > Hmmm...what's that "-framework Python" business? Looks mighty > suspicious in light of the otool output. Again, no idea. IANAC (I am not a coder) :) -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Tom Lane wrote: >"Jim C. Nasby" <decibel@decibel.org> writes: > > >>On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote: >> >> >>>"Jim C. Nasby" <decibel@decibel.org> writes: >>> >>> >>>>Attached is a plpython_error_1.out file that will fix cuckoo. >>>> >>>> >>>What is the reason for the difference in the error message spelling >>>in the first place? Is this a Python version thing (and if so, >>>which version is newer --- that should have pride of place as >>>plpython_error.out I should think)? Or is there some other reason >>>that we need to understand more closely instead of just slapping on >>>a band-aid? >>> >>> > > > >>I don't think it's a version issue; cuckoo is at 2.4, platypus used to >>be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but >>platypus kept working. >> >> > >Hmm ... if it's *not* a version thing then I really do want to know >what's causing it. Anyone have an idea why this machine is saying >'\u80' where everyone else's python says u'\x80' ? > > > > > Another OSX box on buildfarm, wallaroo, is exhibiting the same behaviour, albeit currently masked by interval regression failures. cheers andrew
On Sat, Jul 23, 2005 at 07:58:21PM -0400, Andrew Dunstan wrote: > Tom Lane wrote: > >"Jim C. Nasby" <decibel@decibel.org> writes: > >>I don't think it's a version issue; cuckoo is at 2.4, platypus used to > >>be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but > >>platypus kept working. > > > >Hmm ... if it's *not* a version thing then I really do want to know > >what's causing it. Anyone have an idea why this machine is saying > >'\u80' where everyone else's python says u'\x80' ? > > Another OSX box on buildfarm, wallaroo, is exhibiting the same > behaviour, albeit currently masked by interval regression failures. I suspect this is indeed a Python version issue: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00669.php http://archives.postgresql.org/pgsql-hackers/2005-07/msg00684.php It looks like the Macs have some kind of Python framework that PL/Python is linking against even if a newer version of Python has been installed. Unfortunately I don't have a Mac I could use to do any deeper investigating. The regression tests that are failing are from the patch I submitted about a month ago to fix a core dump in PL/Python: http://archives.postgresql.org/pgsql-patches/2005-06/msg00519.php The tests exercise the error checking that the patch added, doing things that previously caused a segmentation fault but that now raise an exception. Should those tests remain in place? If so, should we rewrite them to avoid the version-specific Python messages (possibly by wrapping them in a PL/pgSQL function that traps the errors), or should we just leave the tests alone now that we think we understand what's happening? -- Michael Fuhr http://www.fuhr.org/~mfuhr/
Michael Fuhr <mike@fuhr.org> writes: >> Tom Lane wrote: >>> Hmm ... if it's *not* a version thing then I really do want to know >>> what's causing it. Anyone have an idea why this machine is saying >>> '\u80' where everyone else's python says u'\x80' ? > The regression tests that are failing are from the patch I submitted > about a month ago to fix a core dump in PL/Python: > http://archives.postgresql.org/pgsql-patches/2005-06/msg00519.php > The tests exercise the error checking that the patch added, doing > things that previously caused a segmentation fault but that now > raise an exception. Should those tests remain in place? If so, > should we rewrite them to avoid the version-specific Python messages > (possibly by wrapping them in a PL/pgSQL function that traps the > errors), or should we just leave the tests alone now that we think > we understand what's happening? Well, if it is just a Python version issue then all we need do is add a variant expected-output file to match. I was just expressing a desire to know that for sure before we wallpaper over the symptom... regards, tom lane
On Sat, Jul 23, 2005 at 10:38:59PM -0400, Tom Lane wrote: > Well, if it is just a Python version issue then all we need do is add > a variant expected-output file to match. I was just expressing a > desire to know that for sure before we wallpaper over the symptom... I just built Python 2.3 and it does indeed format the error differently than later versions (the format appears to have changed in 2.3.1): % python2.3 Python 2.3 (#1, Jul 24 2005, 06:18:30) [GCC 3.4.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> str(u'\x80') Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character '\u80' in position 0: ordinal not in range(128) % python2.4 Python 2.4.1 (#1, Apr 6 2005, 09:52:02) [GCC 3.4.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> str(u'\x80') Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128) One could check the version of Python that PL/Python is using with the following function (assuming that Python isn't so broken that it would use the core of one version but find modules from another): CREATE FUNCTION pyversion() RETURNS text AS $$ import sys return sys.version $$ LANGUAGE plpythonu; I've attached two new files that should go in the plpython directory: resultmap expected/plpython_error_py23.out A problem with this patch is that it assumes a version of Python based on the OS, which might clean up the current buildfarm but that isn't really correct. Is there a better way to handle this? -- Michael Fuhr http://www.fuhr.org/~mfuhr/
Вложения
Michael Fuhr said: > I just built Python 2.3 and it does indeed format the error differently > than later versions (the format appears to have changed in 2.3.1): > [snip] > I've attached two new files that should go in the plpython directory: > > resultmap > expected/plpython_error_py23.out > > A problem with this patch is that it assumes a version of Python > based on the OS, which might clean up the current buildfarm but > that isn't really correct. Is there a better way to handle this? This is completely unnecessary - pg_regress has an alternative result mechanism that doesn't rely on a resultmap file. Just name your alternative result file foo_n.out instead of foo.out, for some n in [0-9]. In this case, call it, say, plpython_error_1.out. Job done, and no OS dependence. cheers andrew
Michael Fuhr <mike@fuhr.org> writes: > A problem with this patch is that it assumes a version of Python > based on the OS, which might clean up the current buildfarm but > that isn't really correct. Is there a better way to handle this? Yes --- just let pg_regress deal with it as if it were a locale problem. I've committed it that way. regards, tom lane
On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote: > This is completely unnecessary - pg_regress has an alternative result > mechanism that doesn't rely on a resultmap file. Just name your alternative > result file foo_n.out instead of foo.out, for some n in [0-9]. In this case, > call it, say, plpython_error_1.out. Job done, and no OS dependence. Thanks -- I overlooked that in src/test/regress/README. -- Michael Fuhr http://www.fuhr.org/~mfuhr/
Michael Fuhr wrote: >On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote: > > >>This is completely unnecessary - pg_regress has an alternative result >>mechanism that doesn't rely on a resultmap file. Just name your alternative >>result file foo_n.out instead of foo.out, for some n in [0-9]. In this case, >>call it, say, plpython_error_1.out. Job done, and no OS dependence. >> >> > >Thanks -- I overlooked that in src/test/regress/README. > > > We should probably generalise that section of the README a bit. People might skip over it thinking "this isn't a locale difference". cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > Michael Fuhr wrote: >> Thanks -- I overlooked that in src/test/regress/README. > We should probably generalise that section of the README a bit. People > might skip over it thinking "this isn't a locale difference". I'm wondering why we still have a README there at all --- it's entirely superseded by the SGML documentation. http://developer.postgresql.org/docs/postgres/regress-evaluation.html regards, tom lane
On Sun, Jul 24, 2005 at 10:55:08AM -0400, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > A problem with this patch is that it assumes a version of Python > > based on the OS, which might clean up the current buildfarm but > > that isn't really correct. Is there a better way to handle this? > > Yes --- just let pg_regress deal with it as if it were a locale > problem. I've committed it that way. > > regards, tom lane > FYI, cuckoo went green with this build: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoo&dt=2005-07-25%2008:05:02 -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Am Sonntag, 24. Juli 2005 17:53 schrieb Tom Lane: > I'm wondering why we still have a README there at all --- it's entirely > superseded by the SGML documentation. > > http://developer.postgresql.org/docs/postgres/regress-evaluation.html I think we kept it there so people can read it during the installation. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes: > Am Sonntag, 24. Juli 2005 17:53 schrieb Tom Lane: >> I'm wondering why we still have a README there at all --- it's entirely >> superseded by the SGML documentation. >> >> http://developer.postgresql.org/docs/postgres/regress-evaluation.html > I think we kept it there so people can read it during the installation. Yeah. I desisted from deleting it after I noticed that there are provisions for re-generating it over in the doc/src/sgml Makefile. However, I'm now wondering why it's not handled exactly like INSTALL --- ie, don't keep it in CVS, but auto-generate it during tarball build. The current manual procedure definitely isn't keeping it up to date. regards, tom lane
Am Freitag, 29. Juli 2005 16:34 schrieb Tom Lane: > Yeah. I desisted from deleting it after I noticed that there are > provisions for re-generating it over in the doc/src/sgml Makefile. > However, I'm now wondering why it's not handled exactly like INSTALL > --- ie, don't keep it in CVS, but auto-generate it during tarball build. > The current manual procedure definitely isn't keeping it up to date. I don't see where the INSTALL file is generated either and put in place either. I suppose this is somewhere in the release building scripts. It should probably be done in the makefiles. -- Peter Eisentraut http://developer.postgresql.org/~petere/