Обсуждение: Is python 2.5 supported?
Since installing python 2.5, tapir has been failing: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=tapir&dt=2006-10-15%2020:20:16 Several of the failures appear to be a simple change in error reporting; I haven't investigated why import_succeed() failed. Should python 2.5 work with plpython? -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim C. Nasby wrote: > Since installing python 2.5, tapir has been failing: I have removed the use of the deprecated whrandom module, which should take care of one regression test failure, but after that I get *** glibc detected *** free(): invalid pointer: 0xa5df6e78 *** LOG: server process (PID 1720) was terminated by signal 6 -- Peter Eisentraut http://developer.postgresql.org/~petere/
Ühel kenal päeval, E, 2006-10-16 kell 14:46, kirjutas Jim C. Nasby: > Since installing python 2.5, tapir has been failing: > > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=tapir&dt=2006-10-15%2020:20:16 > > Several of the failures appear to be a simple change in error reporting; > I haven't investigated why import_succeed() failed. > > Should python 2.5 work with plpython? This is about pl_python ? Forwarding to Sven to investigate -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
Am Dienstag, 17. Oktober 2006 11:59 schrieb Hannu Krosing: > > Several of the failures appear to be a simple change in error reporting; > > I haven't investigated why import_succeed() failed. > > > > Should python 2.5 work with plpython? > > This is about pl_python ? > > Forwarding to Sven to investigate Any news on this? We've had another bug report stating the same issue. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Hello, On Fri, 27 Oct 2006 17:02:15 +0300, Peter Eisentraut <peter_e@gmx.net> wrote: > Am Dienstag, 17. Oktober 2006 11:59 schrieb Hannu Krosing: >> > Several of the failures appear to be a simple change in error >> reporting; >> > I haven't investigated why import_succeed() failed. >> > >> > Should python 2.5 work with plpython? >> >> This is about pl_python ? >> >> Forwarding to Sven to investigate > > Any news on this? We've had another bug report stating the same issue. > Yes, I'm going to action in coming weekend or next week. -- Sven Suursoho mailto:sven.suursoho@skype.net | callto://svensoho Skype Software OÜ, http://www.skype.com Information contained in this email is confidential and proprietary
Peter Eisentraut <peter_e@gmx.net> writes:
> Jim C. Nasby wrote:
>> Since installing python 2.5, tapir has been failing:
> I have removed the use of the deprecated whrandom module, which should
> take care of one regression test failure, but after that I get
> *** glibc detected *** free(): invalid pointer: 0xa5df6e78 ***
> LOG: server process (PID 1720) was terminated by signal 6
A bit of study of the Python documentation suggests that plpython.c is
taking a whole lot of shortcuts in setting up its Python type objects.
For me, this crash goes away with the attached patch ... but I don't
know if it might fail with old Python versions.
There are still a number of regression test diffs, which all look like
Python 2.5 has unilaterally changed the format of object descriptions, eg
! DETAIL: plpy.SPIError: Unknown error in PLy_spi_prepare
vs
! DETAIL: <class 'plpy.SPIError'>: Unknown error in PLy_spi_prepare
Probably there's no help for that except to have two expected files.
regards, tom lane
Index: plpython.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.89
diff -c -r1.89 plpython.c
*** plpython.c 4 Oct 2006 00:30:14 -0000 1.89
--- plpython.c 6 Nov 2006 15:45:58 -0000
***************
*** 1981,1987 **** 0, /* tp_getattro */ 0, /* tp_setattro
*/ 0, /* tp_as_buffer */
! 0, /* tp_xxx4 */ PLy_plan_doc, /* tp_doc */ };
--- 1981,1987 ---- 0, /* tp_getattro */ 0, /* tp_setattro
*/ 0, /* tp_as_buffer */
! Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /* tp_flags */ PLy_plan_doc, /* tp_doc */ };
***************
*** 2026,2032 **** 0, /* tp_getattro */ 0, /* tp_setattro
*/ 0, /* tp_as_buffer */
! 0, /* tp_xxx4 */ PLy_result_doc, /* tp_doc */ };
--- 2026,2032 ---- 0, /* tp_getattro */ 0, /* tp_setattro
*/ 0, /* tp_as_buffer */
! Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /* tp_flags */ PLy_result_doc, /* tp_doc */ };
***************
*** 2098,2104 **** PLy_free(ob->args); }
! PyMem_DEL(arg); }
--- 2098,2104 ---- PLy_free(ob->args); }
! arg->ob_type->tp_free(arg); }
***************
*** 2152,2158 **** Py_XDECREF(ob->rows); Py_XDECREF(ob->status);
! PyMem_DEL(ob); } static PyObject *
--- 2152,2158 ---- Py_XDECREF(ob->rows); Py_XDECREF(ob->status);
! arg->ob_type->tp_free(arg); } static PyObject *
***************
*** 2701,2707 **** /* * initialize plpy module */
! PLy_PlanType.ob_type = PLy_ResultType.ob_type = &PyType_Type; plpy = Py_InitModule("plpy", PLy_methods);
plpy_dict= PyModule_GetDict(plpy);
--- 2701,2711 ---- /* * initialize plpy module */
! if (PyType_Ready(&PLy_PlanType) < 0)
! elog(ERROR, "could not init PLy_PlanType");
! if (PyType_Ready(&PLy_ResultType) < 0)
! elog(ERROR, "could not init PLy_ResultType");
! plpy = Py_InitModule("plpy", PLy_methods); plpy_dict = PyModule_GetDict(plpy);