Re: Making plpython 2 and 3 coexist a bit better

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Making plpython 2 and 3 coexist a bit better
Date: 2016-01-11 19:46:58
Message-ID: 865.1452541618@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> 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 traceable FATAL (or even PANIC) over data corruption every
> time. But I'm guessing that if you tried to use both you'd pretty
> immediately end up crashing the backend.

Yeah, the conservative solution would definitely be to use FATAL.
It's still a usability improvement over what we have now.

In further experimentation, I found out that even with this patch in
place, the plpython transform extensions still present a dump/reload
hazard:

test=# create extension plpython2u;
CREATE EXTENSION
test=# create extension ltree_plpython3u cascade;
NOTICE: installing required extension "ltree"
NOTICE: installing required extension "plpython3u"
ERROR: multiple Python libraries are present in session
DETAIL: Only one Python major version can be used in one session.

AFAICS, the reason for that is this code in the transform extension
scripts:

-- make sure the prerequisite libraries are loaded
DO '1' LANGUAGE plpython3u;

It does appear that we need something for this, because if you just
remove it you get failures like

Symbol not found: _PLyUnicode_FromStringAndSize

But I wonder why we couldn't make it do

LOAD 'plpython3';

instead. If I change the script like that, it seems to go through fine
even with both Python libraries loaded, because CREATE TRANSFORM does not
actually call into the language implementation.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladimir Sitnikov 2016-01-11 19:50:55 Re: Driver behaves differently with prepareThreshold and timestamp fields when daylights is active (was Re: Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102)
Previous Message Simon Riggs 2016-01-11 19:39:14 Re: Speedup twophase transactions