Thread: Patch to fix plpython on OS X
Attached is a plpython_error_1.out file that will fix cuckoo. Unfortunately, I couldn't figure out how to submit it as an actual patch, so it's just a file attachment. It should go in src/pl/plpython/expected. -- 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?"
Attachment
"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?
regards, tom lane
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. -- 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?"
"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/
Attachment
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?"