Re: Extensions vs. shared procedural language handler functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extensions vs. shared procedural language handler functions
Date: 2011-03-05 17:17:48
Message-ID: 21224.1299345468@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The only easy fix I can see at the moment is to arbitrarily create two
>> pg_proc entries --- they can both point at the same C function, but
>> there need to be two of 'em.

> So for 9.1, I think you took the simplest path available.

It's never that easy :-(. I've been trying to figure out why frogmouth
(Windows/cygwin buildfarm member) suddenly started failing:

CREATE EXTENSION plpython2u;
-- really stupid function just to get the module loaded
CREATE FUNCTION stupid() RETURNS text AS 'return "zarkon"' LANGUAGE plpythonu;
! ERROR: could not load library "c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/inst/lib/postgresql/plpython.dll": Invalid access to memory location.

+ select stupid();
+ ERROR: function stupid() does not exist

and it just hit me what must be going on. plpython's makefile tries to
symlink plpython.dll to plpython2.dll, but that trick evidently
doesn't work on Windows: the system doesn't understand they're the same
library and so trying to load both of them at once fails as above.
The next question is how come this regression test ever worked on that
platform. The reason is that up till my changes for $SUBJECT, when you
issued "CREATE LANGUAGE plpython2u" in a database that already had
plpythonu installed, CREATE LANGUAGE found C functions of the expected
names already present and so it didn't create new ones. This meant that
only plpython.dll ever got loaded, not plpython2.dll, despite what the
pg_pltemplate entry alleges about the shlib name for the latter.

IMO this is all pretty Rube Goldbergian and it's amazing it didn't fail
on more platforms. What I propose to do about it is get rid of the
plpython.dll symlink and just have the pg_pltemplate entry for plpythonu
reference the plpython2 shlib. People who want to switch the referent
for plpythonu to be Python3 will have an extra thing to do, but I
haven't heard of very many people doing that anyway.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yeb Havinga 2011-03-05 17:25:31 Re: Sync Rep v19
Previous Message Stefan Huehner 2011-03-05 17:01:35 Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)