[BUGS] BUG #6532: pg_upgrade fails on Python stored procedures
The following bug has been logged on the website: Bug reference: 6532 Logged by: Stuart Bishop Email address: stu...@stuartbishop.net PostgreSQL version: 9.1.3 Operating system: Ubuntu Description: The 9.1.3 changelog states pg_upgrade's handing of plpython stored procedures was fixed, but that does not appear to be the case: postgres@aargh:~$ /usr/lib/postgresql/9.1/bin/pg_upgrade --version pg_upgrade (PostgreSQL) 9.1.3 postgres@aargh:~$ /usr/lib/postgresql/9.1/bin/pg_upgrade --old-bindir=/usr/lib/postgresql/8.4/bin --new-bindir=/usr/lib/postgresql/9.1/bin --old-datadir=8.4/main --new-datadir=9.1/mig --old-port=5433 --new-port=5435 Performing Consistency Checks - Checking current, bin, and data directories ok Checking cluster versions ok Checking database user is a superuser ok Checking for prepared transactions ok Checking for reg* system oid user data typesok Checking for contrib/isn with bigint-passing mismatch ok Checking for large objects ok Creating catalog dump ok Checking for prepared transactions ok Checking for presence of required libraries ok | If pg_upgrade fails after this point, you must | re-initdb the new cluster before continuing. | You will also need to remove the ".old" suffix | from 8.4/main/global/pg_control.old. Performing Upgrade -- Adding ".old" suffix to old global/pg_control ok Analyzing all rows in the new cluster ok Freezing all rows on the new clusterok Deleting new commit clogs ok Copying old commit clogs to new server ok Setting next transaction id for new cluster ok Resetting WAL archives ok Setting frozenxid counters in new cluster ok Creating databases in the new cluster ok Adding support functions to new cluster ok Restoring database schema to new cluster psql:/var/lib/postgresql/pg_upgrade_dump_db.sql:3992: ERROR: could not access file "$libdir/plpython": No such file or directory There were problems executing "/usr/lib/postgresql/9.1/bin/psql" --set ON_ERROR_STOP=on --no-psqlrc --port 5435 --username "postgres" -f "/var/lib/postgresql/pg_upgrade_dump_db.sql" --dbname template1 >> "/dev/null" Failure, exiting The relevant section of pg_upgrade_dump_db.sql is: CREATE FUNCTION plpython_call_handler() RETURNS language_handler LANGUAGE c AS '$libdir/plpython', 'plpython_call_handler'; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures
Hi, On Thursday, March 15, 2012 02:13:29 PM stu...@stuartbishop.net wrote: > The 9.1.3 changelog states pg_upgrade's handing of plpython stored > procedures was fixed, but that does not appear to be the case: > ... > access file "$libdir/plpython": No such file or directory Well. That looks like you didn't install plpython on the new cluster. Are you sure its there? Andres -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures
On Thu, Mar 15, 2012 at 8:54 PM, Andres Freund wrote: > Hi, > > On Thursday, March 15, 2012 02:13:29 PM stu...@stuartbishop.net wrote: >> The 9.1.3 changelog states pg_upgrade's handing of plpython stored >> procedures was fixed, but that does not appear to be the case: >> ... >> access file "$libdir/plpython": No such file or directory > Well. That looks like you didn't install plpython on the new cluster. Are you > sure its there? Yes, it is there. I can see the library with the new name of plpython2.so, not the old plpython.so from 8.4. createlang installs the language just fine if I build a cluster and database myself. -- Stuart Bishop http://www.stuartbishop.net/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures
On Thu, Mar 15, 2012 at 9:01 PM, Stuart Bishop wrote: > Yes, it is there. I can see the library with the new name of > plpython2.so, not the old plpython.so from 8.4. createlang installs > the language just fine if I build a cluster and database myself. As expected, symlinking plpython2.so to plpython.so works around things. I have no idea if this work around will cause problems when upgrading the db to PG 9.2+. -- Stuart Bishop http://www.stuartbishop.net/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6534: Passing numeric Bind variables to ODBC driver convers to "Double precision"
The following bug has been logged on the website: Bug reference: 6534 Logged by: Barry Bell Email address: barry_b...@harte-hanks.com PostgreSQL version: 9.1.2 Operating system: Windows Server 2003 Description: Using the lastest of ODBC ANSI driver for windows 32bit ver 9.00.03 Calling from MS VFP 9.0 public nvar as interger nvar=1 running the following sql: "( select function_pkg(?nvar) " The bind variable nvar will show in postgres as "Double Precision" format instead of integer. Is there a setting on the ODBC driver for incoming vairables? If not it is a buf. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6533: postgre server crashes by create function (create table as)
The following bug has been logged on the website: Bug reference: 6533 Logged by: Alex Sanin Email address: voz...@gmail.com PostgreSQL version: 9.0.4 Operating system: Windows XP sp3 Description: Here is the script: drop table if exists test; CREATE TABLE test ( id serial NOT NULL, lastname character varying(255) NOT NULL, firstname character varying(255), middlename character varying(255), birthdate date, listid integer, CONSTRAINT test_pkey PRIMARY KEY (id) ) WITH ( OIDS=FALSE ); insert into test select a, a::character varying, a::character varying, a::character varying, now()::date + a, a from generate_series(1,1) t(a); CREATE OR REPLACE FUNCTION create_test_child() RETURNS void AS $$ DROP TABLE IF EXISTS test_child; CREATE TABLE test_child AS SELECT test.* FROM test as test; $$ LANGUAGE sql VOLATILE; select create_test_child(); - -same without aliases drop table if exists test; CREATE TABLE test ( id serial NOT NULL, lastname character varying(255) NOT NULL, firstname character varying(255), middlename character varying(255), birthdate date, listid integer, CONSTRAINT test_pkey PRIMARY KEY (id) ) WITH ( OIDS=FALSE ); insert into test select a, a::character varying, a::character varying, a::character varying, now()::date + a, a from generate_series(1,1) t(a); CREATE OR REPLACE FUNCTION create_test_child() RETURNS void AS $$ DROP TABLE IF EXISTS test_child; CREATE TABLE test_child AS SELECT * FROM test; $$ LANGUAGE sql VOLATILE; select create_test_child(); -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures
On Thu, Mar 15, 2012 at 01:13:29PM +, stu...@stuartbishop.net wrote: > The following bug has been logged on the website: > > Bug reference: 6532 > Logged by: Stuart Bishop > Email address: stu...@stuartbishop.net > PostgreSQL version: 9.1.3 > Operating system: Ubuntu > Description: > > The 9.1.3 changelog states pg_upgrade's handing of plpython stored > procedures was fixed, but that does not appear to be the case: The change in 9.1.3 was to allow the pg_upgrade code which checks if all the shared librarires are in place to see plpython.so as equivalent to plpython2.so. I did not modify pg_dump at all, which is where you are seeing the error. > There were problems executing "/usr/lib/postgresql/9.1/bin/psql" --set > ON_ERROR_STOP=on --no-psqlrc --port 5435 --username "postgres" -f > "/var/lib/postgresql/pg_upgrade_dump_db.sql" --dbname template1 >> > "/dev/null" > Failure, exiting > > > The relevant section of pg_upgrade_dump_db.sql is: > > CREATE FUNCTION plpython_call_handler() RETURNS language_handler > LANGUAGE c > AS '$libdir/plpython', 'plpython_call_handler'; OK, I am pretty confused by this. Here is all I get in the pg_dumpall --binary-upgrade output for plpython when I create one plpython function: -- -- Name: plpythonu; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: postgres -- CREATE OR REPLACE PROCEDURAL LANGUAGE plpythonu; ALTER PROCEDURAL LANGUAGE plpythonu OWNER TO postgres; SET search_path = public, pg_catalog; -- -- Name: pymax(integer, integer); Type: FUNCTION; Schema: public; Owner: postgres -- CREATE FUNCTION pymax(a integer, b integer) RETURNS integer LANGUAGE plpythonu AS $$ if a > b: return a return b $$; ALTER FUNCTION public.pymax(a integer, b integer) OWNER TO postgres; I have repeatedly upgraded from 9.0.X to 9.1.3 and am seeing no failures. The big question is what are you doing that is causing the plpython_call_handler() function to be dumped? That is an internal function. What is your old PG version? I tested 8.4 and also could not get the failure you see either. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6511: calling spi_exec_query from non-main package, results in: couldn't fetch $_TD
On Tue, Mar 06, 2012 at 09:08:25PM -0700, Alex Hunsaker wrote:
> [ Calling a plperl trigger function from a plperl function ]
>
> Yeah, there were some optimization done for 9.1 to try and make calls
> a bit faster. The problem is we are fetching "_TD" not "main::_TD",
> which means we try to find and use $_TD from whatever the current
> package is. This should only happen from a nested plperl to plperl
> trigger where the outer call was in a different package, otherwise the
> package is always main.
>
> The attached fixes it for me, It would be great if you could confirm that.
>
> Thanks for the report!
So, should this be applied?
---
> *** a/src/pl/plperl/plperl.c
> --- b/src/pl/plperl/plperl.c
> ***
> *** 2062,2068 plperl_call_perl_trigger_func(plperl_proc_desc *desc,
> FunctionCallInfo fcinfo,
> ENTER;
> SAVETMPS;
>
> ! TDsv = get_sv("_TD", 0);
> if (!TDsv)
> elog(ERROR, "couldn't fetch $_TD");
>
> --- 2062,2068
> ENTER;
> SAVETMPS;
>
> ! TDsv = get_sv("main::_TD", 0);
> if (!TDsv)
> elog(ERROR, "couldn't fetch $_TD");
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6533: postgre server crashes by create function (create table as)
voz...@gmail.com writes: > The following bug has been logged on the website: > Bug reference: 6533 > Logged by: Alex Sanin > Email address: voz...@gmail.com > PostgreSQL version: 9.0.4 > Operating system: Windows XP sp3 > Description: > Here is the script: This script doesn't crash for me, in HEAD or 9.0 branch tip. Given the use of CREATE TABLE AS in a SQL function, I suspect that this is the same issue fixed in 9.0.7: Fix dangling pointer after CREATE TABLE AS/SELECT INTO in a SQL-language function (Tom Lane) In most cases this only led to an assertion failure in assert-enabled builds, but worse consequences seem possible. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
