|
|
|
/*
|
|
|
|
* function.c
|
|
|
|
*
|
|
|
|
* server-side function support
|
|
|
|
*
|
|
|
|
* Copyright (c) 2010-2018, PostgreSQL Global Development Group
|
|
|
|
* src/bin/pg_upgrade/function.c
|
|
|
|
*/
|
|
|
|
|
Create libpgcommon, and move pg_malloc et al to it
libpgcommon is a new static library to allow sharing code among the
various frontend programs and backend; this lets us eliminate duplicate
implementations of common routines. We avoid libpgport, because that's
intended as a place for porting issues; per discussion, it seems better
to keep them separate.
The first use case, and the only implemented by this patch, is pg_malloc
and friends, which many frontend programs were already using.
At the same time, we can use this to provide palloc emulation functions
for the frontend; this way, some palloc-using files in the backend can
also be used by the frontend cleanly. To do this, we change palloc() in
the backend to be a function instead of a macro on top of
MemoryContextAlloc(). This was previously believed to cause loss of
performance, but this implementation has been tweaked by Tom and Andres
so that on modern compilers it provides a slight improvement over the
previous one.
This lets us clean up some places that were already with
localized hacks.
Most of the pg_malloc/palloc changes in this patch were authored by
Andres Freund. Zoltán Böszörményi also independently provided a form of
that. libpgcommon infrastructure was authored by Álvaro.
13 years ago
|
|
|
#include "postgres_fe.h"
|
|
|
|
|
|
|
|
#include "pg_upgrade.h"
|
|
|
|
|
|
|
|
#include "access/transam.h"
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
#include "catalog/pg_language.h"
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* qsort comparator for pointers to library names
|
|
|
|
*
|
|
|
|
* We sort first by name length, then alphabetically for names of the same
|
|
|
|
* length. This is to ensure that, eg, "hstore_plpython" sorts after both
|
|
|
|
* "hstore" and "plpython"; otherwise transform modules will probably fail
|
|
|
|
* their LOAD tests. (The backend ought to cope with that consideration,
|
|
|
|
* but it doesn't yet, and even when it does it'll still be a good idea
|
|
|
|
* to have a predictable order of probing here.)
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
library_name_compare(const void *p1, const void *p2)
|
|
|
|
{
|
|
|
|
const char *str1 = *(const char *const *) p1;
|
|
|
|
const char *str2 = *(const char *const *) p2;
|
|
|
|
int slen1 = strlen(str1);
|
|
|
|
int slen2 = strlen(str2);
|
|
|
|
|
|
|
|
if (slen1 != slen2)
|
|
|
|
return slen1 - slen2;
|
|
|
|
return strcmp(str1, str2);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get_loadable_libraries()
|
|
|
|
*
|
|
|
|
* Fetch the names of all old libraries containing C-language functions.
|
|
|
|
* We will later check that they all exist in the new installation.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
get_loadable_libraries(void)
|
|
|
|
{
|
|
|
|
PGresult **ress;
|
|
|
|
int totaltups;
|
|
|
|
int dbnum;
|
|
|
|
bool found_public_plpython_handler = false;
|
|
|
|
|
|
|
|
ress = (PGresult **) pg_malloc(old_cluster.dbarr.ndbs * sizeof(PGresult *));
|
|
|
|
totaltups = 0;
|
|
|
|
|
|
|
|
/* Fetch all library names, removing duplicates within each DB */
|
|
|
|
for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++)
|
|
|
|
{
|
|
|
|
DbInfo *active_db = &old_cluster.dbarr.dbs[dbnum];
|
|
|
|
PGconn *conn = connectToServer(&old_cluster, active_db->db_name);
|
|
|
|
|
|
|
|
/*
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
* Fetch all libraries containing non-built-in C functions in this DB.
|
|
|
|
*/
|
|
|
|
ress[dbnum] = executeQueryOrDie(conn,
|
|
|
|
"SELECT DISTINCT probin "
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
"FROM pg_catalog.pg_proc "
|
|
|
|
"WHERE prolang = %u AND "
|
|
|
|
"probin IS NOT NULL AND "
|
|
|
|
"oid >= %u;",
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
ClanguageId,
|
|
|
|
FirstNormalObjectId);
|
|
|
|
totaltups += PQntuples(ress[dbnum]);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Systems that install plpython before 8.1 have
|
|
|
|
* plpython_call_handler() defined in the "public" schema, causing
|
|
|
|
* pg_dump to dump it. However that function still references
|
|
|
|
* "plpython" (no "2"), so it throws an error on restore. This code
|
|
|
|
* checks for the problem function, reports affected databases to the
|
|
|
|
* user and explains how to remove them. 8.1 git commit:
|
|
|
|
* e0dedd0559f005d60c69c9772163e69c204bac69
|
|
|
|
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg01101.php
|
|
|
|
* http://archives.postgresql.org/pgsql-bugs/2012-05/msg00206.php
|
|
|
|
*/
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) < 901)
|
|
|
|
{
|
|
|
|
PGresult *res;
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
"SELECT 1 "
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
"FROM pg_catalog.pg_proc p "
|
|
|
|
" JOIN pg_catalog.pg_namespace n "
|
|
|
|
" ON pronamespace = n.oid "
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
"WHERE proname = 'plpython_call_handler' AND "
|
|
|
|
"nspname = 'public' AND "
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
"prolang = %u AND "
|
|
|
|
"probin = '$libdir/plpython' AND "
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
"p.oid >= %u;",
|
|
|
|
ClanguageId,
|
|
|
|
FirstNormalObjectId);
|
|
|
|
if (PQntuples(res) > 0)
|
|
|
|
{
|
|
|
|
if (!found_public_plpython_handler)
|
|
|
|
{
|
|
|
|
pg_log(PG_WARNING,
|
|
|
|
"\nThe old cluster has a \"plpython_call_handler\" function defined\n"
|
|
|
|
"in the \"public\" schema which is a duplicate of the one defined\n"
|
|
|
|
"in the \"pg_catalog\" schema. You can confirm this by executing\n"
|
|
|
|
"in psql:\n"
|
|
|
|
"\n"
|
|
|
|
" \\df *.plpython_call_handler\n"
|
|
|
|
"\n"
|
|
|
|
"The \"public\" schema version of this function was created by a\n"
|
|
|
|
"pre-8.1 install of plpython, and must be removed for pg_upgrade\n"
|
|
|
|
"to complete because it references a now-obsolete \"plpython\"\n"
|
|
|
|
"shared object file. You can remove the \"public\" schema version\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
"of this function by running the following command:\n"
|
|
|
|
"\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
" DROP FUNCTION public.plpython_call_handler()\n"
|
|
|
|
"\n"
|
|
|
|
"in each affected database:\n"
|
|
|
|
"\n");
|
|
|
|
}
|
|
|
|
pg_log(PG_WARNING, " %s\n", active_db->db_name);
|
|
|
|
found_public_plpython_handler = true;
|
|
|
|
}
|
|
|
|
PQclear(res);
|
|
|
|
}
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (found_public_plpython_handler)
|
|
|
|
pg_fatal("Remove the problem functions from the old cluster to continue.\n");
|
|
|
|
|
|
|
|
/*
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
* Now we want to remove duplicates across DBs and sort the library names
|
|
|
|
* into order. This avoids multiple probes of the same library, and
|
|
|
|
* ensures that libraries are probed in a consistent order, which is
|
|
|
|
* important for reproducible behavior if one library depends on another.
|
|
|
|
*
|
|
|
|
* First transfer all the names into one array, then sort, then remove
|
|
|
|
* duplicates. Note: we strdup each name in the first loop so that we can
|
|
|
|
* safely clear the PGresults in the same loop. This is a bit wasteful
|
|
|
|
* but it's unlikely there are enough names to matter.
|
|
|
|
*/
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
os_info.libraries = (char **) pg_malloc(totaltups * sizeof(char *));
|
|
|
|
totaltups = 0;
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++)
|
|
|
|
{
|
|
|
|
PGresult *res = ress[dbnum];
|
|
|
|
int ntups;
|
|
|
|
int rowno;
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
for (rowno = 0; rowno < ntups; rowno++)
|
|
|
|
{
|
|
|
|
char *lib = PQgetvalue(res, rowno, 0);
|
|
|
|
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
os_info.libraries[totaltups++] = pg_strdup(lib);
|
|
|
|
}
|
|
|
|
PQclear(res);
|
|
|
|
}
|
|
|
|
|
|
|
|
pg_free(ress);
|
Enforce a specific order for probing library loadability in pg_upgrade.
pg_upgrade checks whether all the shared libraries used in the old cluster
are also available in the new one by issuing LOAD for each library name.
Previously, it cared not what order it did the LOADs in. Ideally it
should not have to care, but currently the transform modules in contrib
fail unless both the language and datatype modules they depend on are
loaded first. A backend-side solution for that looks possible but
probably not back-patchable, so as a stopgap measure, let's do the LOAD
tests in order by library name length. That should fix the problem for
reasonably-named transform modules, eg "hstore_plpython" will be loaded
after both "hstore" and "plpython". (Yeah, it's a hack.)
In a larger sense, having a predictable order of these probes is a good
thing, since it will make upgrades predictably work or not work in the
face of inter-library dependencies. Also, this patch replaces O(N^2)
de-duplication logic with O(N log N) logic, which could matter in
installations with very many databases. So I don't foresee reverting this
even after we have a proper fix for the library-dependency problem.
In passing, improve a couple of SQL queries used here.
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib
modules failed. Back-patch to 9.5 where transform modules were introduced.
Discussion: <f7ac29f3-515c-2a44-21c5-ec925053265f@dunslane.net>
9 years ago
|
|
|
|
|
|
|
if (totaltups > 1)
|
|
|
|
{
|
|
|
|
int i,
|
|
|
|
lastnondup;
|
|
|
|
|
|
|
|
qsort((void *) os_info.libraries, totaltups, sizeof(char *),
|
|
|
|
library_name_compare);
|
|
|
|
|
|
|
|
for (i = 1, lastnondup = 0; i < totaltups; i++)
|
|
|
|
{
|
|
|
|
if (strcmp(os_info.libraries[i],
|
|
|
|
os_info.libraries[lastnondup]) != 0)
|
|
|
|
os_info.libraries[++lastnondup] = os_info.libraries[i];
|
|
|
|
else
|
|
|
|
pg_free(os_info.libraries[i]);
|
|
|
|
}
|
|
|
|
totaltups = lastnondup + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
os_info.num_libraries = totaltups;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* check_loadable_libraries()
|
|
|
|
*
|
|
|
|
* Check that the new cluster contains all required libraries.
|
|
|
|
* We do this by actually trying to LOAD each one, thereby testing
|
|
|
|
* compatibility as well as presence.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
check_loadable_libraries(void)
|
|
|
|
{
|
|
|
|
PGconn *conn = connectToServer(&new_cluster, "template1");
|
|
|
|
int libnum;
|
|
|
|
FILE *script = NULL;
|
|
|
|
bool found = false;
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
|
|
prep_status("Checking for presence of required libraries");
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path), "loadable_libraries.txt");
|
|
|
|
|
|
|
|
for (libnum = 0; libnum < os_info.num_libraries; libnum++)
|
|
|
|
{
|
|
|
|
char *lib = os_info.libraries[libnum];
|
|
|
|
int llen = strlen(lib);
|
|
|
|
char cmd[7 + 2 * MAXPGPATH + 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.
|
|
|
|
*
|
|
|
|
* For this case, we could check pg_pltemplate, but that only works
|
|
|
|
* for languages, and does not help with function shared objects, so
|
|
|
|
* we just do a general fix.
|
|
|
|
*/
|
|
|
|
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);
|
|
|
|
|
|
|
|
if (PQresultStatus(res) != PGRES_COMMAND_OK)
|
|
|
|
{
|
|
|
|
found = true;
|
|
|
|
|
|
|
|
if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL)
|
Improve error reporting in pg_upgrade's file copying/linking/rewriting.
The previous design for this had copyFile(), linkFile(), and
rewriteVisibilityMap() returning strerror strings, with the caller
producing one-size-fits-all error messages based on that. This made it
impossible to produce messages that described the failures with any degree
of precision, especially not short-read problems since those don't set
errno at all.
Since pg_upgrade has no intention of continuing after any error in this
area, let's fix this by just letting these functions call pg_fatal() for
themselves, making it easy for each point of failure to have a suitable
error message. Taking this approach also allows dropping cleanup code
that was unnecessary and was often rather sloppy about preserving errno.
To not lose relevant info that was reported before, pass in the schema name
and table name of the current table so that they can be included in the
error reports.
An additional problem was the use of getErrorText(), which was flat out
wrong for all but a couple of call sites, because it unconditionally did
"_dosmaperr(GetLastError())" on Windows. That's only appropriate when
reporting an error from a Windows-native API, which only a couple of
the callers were actually doing. Thus, even the reported strerror string
would be unrelated to the actual failure in many cases on Windows.
To fix, get rid of getErrorText() altogether, and just have call sites
do strerror(errno) instead, since that's the way all the rest of our
frontend programs do it. Add back the _dosmaperr() calls in the two
places where that's actually appropriate.
In passing, make assorted messages hew more closely to project style
guidelines, notably by removing initial capitals in not-complete-sentence
primary error messages. (I didn't make any effort to clean up places
I didn't have another reason to touch, though.)
Per discussion of a report from Thomas Kellerer. Back-patch to 9.6,
but no further; given the relative infrequency of reports of problems
here, it's not clear it's worth adapting the patch to older branches.
Patch by me, but with credit to Alvaro Herrera for spotting the issue
with getErrorText's misuse of _dosmaperr().
Discussion: <nsjrbh$8li$1@blaine.gmane.org>
9 years ago
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
output_path, strerror(errno));
|
|
|
|
fprintf(script, _("could not load library \"%s\": %s"),
|
|
|
|
lib,
|
|
|
|
PQerrorMessage(conn));
|
|
|
|
}
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
}
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
{
|
|
|
|
fclose(script);
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
pg_fatal("Your installation references loadable libraries that are missing from the\n"
|
|
|
|
"new installation. You can add these libraries to the new installation,\n"
|
|
|
|
"or remove the functions using them from the old installation. A list of\n"
|
|
|
|
"problem libraries is in the file:\n"
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
check_ok();
|
|
|
|
}
|