Re: [HACKERS] pg_upgrade with plpython is broken
On Fri, Jan 20, 2012 at 07:01:46AM +0200, Peter Eisentraut wrote: > On tor, 2012-01-19 at 17:04 -0500, Bruce Momjian wrote: > > For that reason, I wonder if I should just hard-code the plpython > > rename into the pg_upgrade test in check_loadable_libraries(). > > Yes, I haven't come up with a better solution either. > > If this becomes a general problem, we might need to add a command line > option to ignore certain names or something. But not yet. Well, the problem is a little more complex than reported. It turns out in PG 9.0 we kept the plpython.so file and symlinked plpython2.so to it. In PG 9.1, we removed plpython.so, and only have plpython2.so, so the problem is with PG >= 9.1, and does not affect 9.0, which explains why we didn't get any 9.0 reports of a problem. I have applied the attached patch to PG head and 9.1 to fix the library checking problem. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/contrib/pg_upgrade/function.c b/contrib/pg_upgrade/function.c new file mode 100644 index 54f139a..4505e51 *** a/contrib/pg_upgrade/function.c --- b/contrib/pg_upgrade/function.c *** check_loadable_libraries(void) *** 228,235 char *cmd = (char *) pg_malloc(8 + 2 * llen + 1); PGresult *res; strcpy(cmd, "LOAD '"); ! PQescapeStringConn(conn, cmd + 6, lib, llen, NULL); strcat(cmd, "'"); res = PQexec(conn, cmd); --- 228,251 char *cmd = (char *) pg_malloc(8 + 2 * llen + 1); PGresult *res; + /* + * In Postgres 9.0, Python 3 support was added, and to do that, a + * plpython2u language was created with library name plpython2.so + * as a symbolic link to plpython.so. In Postgres 9.1, only the + * plpython2.so library was created, and both plpythonu and + * plpython2u pointing to it. For this reason, any reference to + * library name "plpython" in an old PG <= 9.1 cluster must look + * for "plpython2" in the new cluster. + */ + if (GET_MAJOR_VERSION(old_cluster.major_version) < 901 && + strcmp(lib, "$libdir/plpython") == 0) + { + lib = "$libdir/plpython2"; + llen = strlen(lib); + } + strcpy(cmd, "LOAD '"); ! PQescapeStringConn(conn, cmd + strlen(cmd), lib, llen, NULL); strcat(cmd, "'"); res = PQexec(conn, cmd); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade with plpython is broken
On tor, 2012-01-19 at 17:04 -0500, Bruce Momjian wrote: > For that reason, I wonder if I should just hard-code the plpython > rename into the pg_upgrade test in check_loadable_libraries(). Yes, I haven't come up with a better solution either. If this becomes a general problem, we might need to add a command line option to ignore certain names or something. But not yet. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade with plpython is broken
On Thu, Dec 22, 2011 at 11:42:23AM -0500, Robert Haas wrote: > On Mon, Dec 19, 2011 at 10:16 AM, Peter Eisentraut wrote: > > Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken > > because the module plpython.so was renamed to plpython2.so, and so the > > pg_upgrade check for loadable libraries fails thus: > > > > Your installation references loadable libraries that are missing from the > > new installation. etc. > > > > Installing a symlink fixes the issue. Should we teach pg_upgrade about > > this renaming, or should we install the symlink as part of the standard > > installation? > > I feel like this is a pg_upgrade bug, not so much a PL/python problem. I looked into this and the problem is coming from the checking of pg_proc library functions (not explicitly _language_ functions): plpython_call_handler| $libdir/plpython2 plpython_inline_handler | $libdir/plpython2 plpython_validator | $libdir/plpython2 All three of these entries relate to plpython, and obviously you can see the library name change. The list of required libraries is generated in the old cluster. One interesting solution would be to lookup the matching function names from the new cluster's pg_pltemplate, and use that library name. That would fix the problem of language library files being renamed, but not address non-language library file names being renamed --- there is no _template_ to look for these new values. I hate to add a complex fix for languages and leave the non-language cases unfixed. For that reason, I wonder if I should just hard-code the plpython rename into the pg_upgrade test in check_loadable_libraries(). -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade with plpython is broken
On Mon, Dec 19, 2011 at 10:16 AM, Peter Eisentraut wrote: > Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken > because the module plpython.so was renamed to plpython2.so, and so the > pg_upgrade check for loadable libraries fails thus: > > Your installation references loadable libraries that are missing from the > new installation. etc. > > Installing a symlink fixes the issue. Should we teach pg_upgrade about > this renaming, or should we install the symlink as part of the standard > installation? I feel like this is a pg_upgrade bug, not so much a PL/python problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_upgrade with plpython is broken
Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken because the module plpython.so was renamed to plpython2.so, and so the pg_upgrade check for loadable libraries fails thus: Your installation references loadable libraries that are missing from the new installation. etc. Installing a symlink fixes the issue. Should we teach pg_upgrade about this renaming, or should we install the symlink as part of the standard installation? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers