Skip site navigation (1) Skip section navigation (2)

Re: plpython improvements

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Sven Suursoho <sven(at)spam(dot)pri(dot)ee>
Cc: Marko Kreen <markokr(at)gmail(dot)com>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-patches(at)postgresql(dot)org
Subject: Re: plpython improvements
Date: 2006-05-05 13:55:29
Message-ID: 1146837329.3830.17.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-patches
Ühel kenal päeval, N, 2006-05-04 kell 18:21, kirjutas Sven Suursoho:
> Hi,
> 
> 
> Sun, 30 Apr 2006 19:14:28 +0300, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 
> > "Sven Suursoho" <sven(at)spam(dot)pri(dot)ee> writes:
> >> Unfortunately, there is still one problem when using unpatched python,
> >> caused by too aggressive assert.
> >> http://mail.python.org/pipermail/python-checkins/2005-August/046571.html.
> >
> > I don't think we are going to be able to accept a patch that causes the
> > server to crash when using any but a bleeding-edge copy of Python.

Actually not bleeding-edge, but just version 2.4.x as distributed in
Fedora Core (and possibly in RHAS), which have assert() enabled in
python.so. 

The assert there is buggy (bug
http://sourceforge.net/tracker/index.php?func=detail&aid=1257960&group_id=5470&atid=105470) 

> Did complete rewrite for SETOF functions: now accepts any python object  
> for which iter(object) returns iterable object. In this way we don't have  
> to deal with specific containers but can use unified python iterator API.  
> It means that plpython is future-proof -- whenever python introduces new  
> container, stored procedures already can use those without recompiling  
> language handler.
> 
> Also integrated with regression tests and updated existing tests to use  
> named parameters.
> 
> When using python interpreter with asserts enabled, generators still  
> crash. But I don't think that we should drop this feature because of that.  
> Reasons:
> 1) this is someone else's bug, we are using documented API correctly
> 2) it doesn't concern majority of users because probably there is no  
> asserts in production packages (tested with gentoo, ubuntu, suse). This is  
> true even for older python versions that are not patched.

>From reading the bug, it seems that older versions of python also don't
have this bug, only 2.4.

> And after all, we can document using sets, lists, tuples, iterators etc  
> and explicitly state that returning generator is undefined.

I think that a less confusing way of saying it would be :

 "Generators crash if python version used is 2.4.x and it is compiled
 with asserts. 

 Currently only known linux distributions to distibute such python.so
 files are Fedora and possibly other RedHat distributions, while
 Gentoo, Ubuntu and Suse are OK. 

 If you need to use generators on such a platform, compile your own 
 python from source and make sure that configure uses your version."


I think the patch should be commited so we can collect data about where
else the buggy version of python exists.

And if some buildfarm machines start crashing, python should be fixed
there.

----------------
Hannu




In response to

Responses

pgsql-patches by date

Next:From: Robert LorDate: 2006-05-05 15:50:55
Subject: Re: [BUGS] BUG #2401: spinlocks not available on amd64
Previous:From: Martijn van OosterhoutDate: 2006-05-05 13:34:38
Subject: Re: Have configure complain about unknown options

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group