Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-18 Thread Bruce Momjian
On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote: > Commit 803716013dc1350f installed a safeguard against loading plpython2 > and plpython3 at the same time, stating > > + It is not allowed to use PL/Python based on Python 2 and PL/Python > + based on Python 3 in the same session,

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-18 Thread Tom Lane
Bruce Momjian writes: > On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote: >> But it gets worse: a report today in pgsql-general points out that >> even if you have the two languages in use *in different databases*, >> pg_upgrade will fail, because pg_upgrade rather

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-18 Thread Bruce Momjian
On Mon, Jan 18, 2016 at 01:10:05PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote: > >> But it gets worse: a report today in pgsql-general points out that > >> even if you have the two languages in use *in different

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-11 Thread Tom Lane
I wrote: > In further experimentation, I found out that even with this patch in > place, the plpython transform extensions still present a dump/reload > hazard: > ... > But I wonder why we couldn't make it do > LOAD 'plpython3'; I've verified that the attached additional patch makes everything

[HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-11 Thread Tom Lane
Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, stating + It is not allowed to use PL/Python based on Python 2 and PL/Python + based on Python 3 in the same session, because the symbols in the + dynamic modules would clash, which could

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-11 Thread Jim Nasby
On 1/11/16 11:51 AM, Tom Lane wrote: We could ameliorate the first of these cases by putting the can't-run- with-two-pythons error back up to FATAL rather than ERROR, but I'm not sure that that would be a net improvement --- FATAL errors aren't very friendly. In any case errors of the second

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-11 Thread Tom Lane
I wrote: > I think we might be able to improve this if we don't do the check in > plpython's _PG_init(), but delay it until we have a need to call into > libpython; which we could skip doing at _PG_init() time, at the cost > of perhaps one more flag check per plpython function call to see if >

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-11 Thread Tom Lane
Jim Nasby writes: > Something that's always concerned me about functions in other languages > is that any kind of snafu in the function/language can hose the backend, > which you may or may not detect. I've used other databases that (by > default) spin up a separate

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-11 Thread Jim Nasby
On 1/11/16 1:00 PM, Tom Lane wrote: There's at least one PL/Java implementation that does that. The interprocess communication overhead is pretty awful, IIRC. Don't know what they do about nested calls. You'd think that pipes wouldn't be that much overhead... >Obviously this is a lot more

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

2016-01-11 Thread Tom Lane
Jim Nasby writes: > On 1/11/16 1:00 PM, Tom Lane wrote: >> The question of whether to do ERROR or FATAL remains open. I'm not sure >> I have a strong preference either way. > If they both get loaded is there risk of bad data happening? Personally, > I'll take a