2010-05-12 04:19:11 +02:00
|
|
|
/*
|
|
|
|
* info.c
|
|
|
|
*
|
|
|
|
* information support functions
|
2010-07-03 16:23:14 +02:00
|
|
|
*
|
2017-01-03 19:48:53 +01:00
|
|
|
* Copyright (c) 2010-2017, PostgreSQL Global Development Group
|
2015-03-11 03:33:25 +01:00
|
|
|
* src/bin/pg_upgrade/info.c
|
2010-05-12 04:19:11 +02:00
|
|
|
*/
|
|
|
|
|
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.
2013-02-12 14:33:40 +01:00
|
|
|
#include "postgres_fe.h"
|
2011-08-27 03:16:24 +02:00
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
#include "pg_upgrade.h"
|
|
|
|
|
|
|
|
#include "access/transam.h"
|
2017-03-10 04:42:16 +01:00
|
|
|
#include "catalog/pg_class.h"
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
2011-01-05 01:11:00 +01:00
|
|
|
static void create_rel_filename_map(const char *old_data, const char *new_data,
|
2011-04-10 17:42:00 +02:00
|
|
|
const DbInfo *old_db, const DbInfo *new_db,
|
|
|
|
const RelInfo *old_rel, const RelInfo *new_rel,
|
|
|
|
FileNameMap *map);
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
static void report_unmatched_relation(const RelInfo *rel, const DbInfo *db,
|
|
|
|
bool is_new_db);
|
2012-11-14 03:10:40 +01:00
|
|
|
static void free_db_and_rel_infos(DbInfoArr *db_arr);
|
2011-01-10 17:45:22 +01:00
|
|
|
static void get_db_infos(ClusterInfo *cluster);
|
|
|
|
static void get_rel_infos(ClusterInfo *cluster, DbInfo *dbinfo);
|
|
|
|
static void free_rel_infos(RelInfoArr *rel_arr);
|
|
|
|
static void print_db_infos(DbInfoArr *dbinfo);
|
2012-12-20 19:56:24 +01:00
|
|
|
static void print_rel_infos(RelInfoArr *rel_arr);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* gen_db_file_maps()
|
|
|
|
*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* generates a database mapping from "old_db" to "new_db".
|
|
|
|
*
|
|
|
|
* Returns a malloc'ed array of mappings. The length of the array
|
|
|
|
* is returned into *nmaps.
|
2010-05-12 04:19:11 +02:00
|
|
|
*/
|
|
|
|
FileNameMap *
|
2010-10-19 23:38:16 +02:00
|
|
|
gen_db_file_maps(DbInfo *old_db, DbInfo *new_db,
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
int *nmaps,
|
|
|
|
const char *old_pgdata, const char *new_pgdata)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
FileNameMap *maps;
|
2015-05-24 03:35:49 +02:00
|
|
|
int old_relnum,
|
|
|
|
new_relnum;
|
2010-05-12 04:19:11 +02:00
|
|
|
int num_maps = 0;
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
bool all_matched = true;
|
2010-05-12 04:19:11 +02:00
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* There will certainly not be more mappings than there are old rels */
|
2010-10-19 23:38:16 +02:00
|
|
|
maps = (FileNameMap *) pg_malloc(sizeof(FileNameMap) *
|
2011-01-05 17:37:08 +01:00
|
|
|
old_db->rel_arr.nrels);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2014-07-07 19:24:08 +02:00
|
|
|
/*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* Each of the RelInfo arrays should be sorted by OID. Scan through them
|
|
|
|
* and match them up. If we fail to match everything, we'll abort, but
|
|
|
|
* first print as much info as we can about mismatches.
|
2014-07-07 19:24:08 +02:00
|
|
|
*/
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
old_relnum = new_relnum = 0;
|
|
|
|
while (old_relnum < old_db->rel_arr.nrels ||
|
|
|
|
new_relnum < new_db->rel_arr.nrels)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
RelInfo *old_rel = (old_relnum < old_db->rel_arr.nrels) ?
|
|
|
|
&old_db->rel_arr.rels[old_relnum] : NULL;
|
|
|
|
RelInfo *new_rel = (new_relnum < new_db->rel_arr.nrels) ?
|
|
|
|
&new_db->rel_arr.rels[new_relnum] : NULL;
|
2014-07-07 19:24:08 +02:00
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* handle running off one array before the other */
|
|
|
|
if (!new_rel)
|
2014-07-07 19:24:08 +02:00
|
|
|
{
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/*
|
|
|
|
* old_rel is unmatched. This should never happen, because we
|
|
|
|
* force new rels to have TOAST tables if the old one did.
|
|
|
|
*/
|
|
|
|
report_unmatched_relation(old_rel, old_db, false);
|
|
|
|
all_matched = false;
|
|
|
|
old_relnum++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!old_rel)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* new_rel is unmatched. This shouldn't really happen either, but
|
|
|
|
* if it's a TOAST table, we can ignore it and continue
|
|
|
|
* processing, assuming that the new server made a TOAST table
|
|
|
|
* that wasn't needed.
|
|
|
|
*/
|
|
|
|
if (strcmp(new_rel->nspname, "pg_toast") != 0)
|
|
|
|
{
|
|
|
|
report_unmatched_relation(new_rel, new_db, true);
|
|
|
|
all_matched = false;
|
|
|
|
}
|
|
|
|
new_relnum++;
|
|
|
|
continue;
|
2014-07-07 19:24:08 +02:00
|
|
|
}
|
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* check for mismatched OID */
|
|
|
|
if (old_rel->reloid < new_rel->reloid)
|
2014-07-07 19:24:08 +02:00
|
|
|
{
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* old_rel is unmatched, see comment above */
|
|
|
|
report_unmatched_relation(old_rel, old_db, false);
|
|
|
|
all_matched = false;
|
|
|
|
old_relnum++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
else if (old_rel->reloid > new_rel->reloid)
|
|
|
|
{
|
|
|
|
/* new_rel is unmatched, see comment above */
|
|
|
|
if (strcmp(new_rel->nspname, "pg_toast") != 0)
|
|
|
|
{
|
|
|
|
report_unmatched_relation(new_rel, new_db, true);
|
|
|
|
all_matched = false;
|
|
|
|
}
|
|
|
|
new_relnum++;
|
|
|
|
continue;
|
2014-07-07 19:24:08 +02:00
|
|
|
}
|
2011-03-06 03:12:21 +01:00
|
|
|
|
2011-03-06 04:09:35 +01:00
|
|
|
/*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* Verify that rels of same OID have same name. The namespace name
|
|
|
|
* should always match, but the relname might not match for TOAST
|
|
|
|
* tables (and, therefore, their indexes).
|
|
|
|
*
|
|
|
|
* TOAST table names initially match the heap pg_class oid, but
|
|
|
|
* pre-9.0 they can change during certain commands such as CLUSTER, so
|
|
|
|
* don't insist on a match if old cluster is < 9.0.
|
2011-03-06 04:09:35 +01:00
|
|
|
*/
|
2011-03-06 12:34:58 +01:00
|
|
|
if (strcmp(old_rel->nspname, new_rel->nspname) != 0 ||
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
(strcmp(old_rel->relname, new_rel->relname) != 0 &&
|
|
|
|
(GET_MAJOR_VERSION(old_cluster.major_version) >= 900 ||
|
|
|
|
strcmp(old_rel->nspname, "pg_toast") != 0)))
|
|
|
|
{
|
|
|
|
pg_log(PG_WARNING, "Relation names for OID %u in database \"%s\" do not match: "
|
|
|
|
"old name \"%s.%s\", new name \"%s.%s\"\n",
|
|
|
|
old_rel->reloid, old_db->db_name,
|
|
|
|
old_rel->nspname, old_rel->relname,
|
|
|
|
new_rel->nspname, new_rel->relname);
|
|
|
|
all_matched = false;
|
|
|
|
old_relnum++;
|
|
|
|
new_relnum++;
|
|
|
|
continue;
|
|
|
|
}
|
2011-03-06 03:12:21 +01:00
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* OK, create a mapping entry */
|
2011-01-05 01:11:00 +01:00
|
|
|
create_rel_filename_map(old_pgdata, new_pgdata, old_db, new_db,
|
2011-04-10 17:42:00 +02:00
|
|
|
old_rel, new_rel, maps + num_maps);
|
2010-05-12 04:19:11 +02:00
|
|
|
num_maps++;
|
2014-07-07 19:24:08 +02:00
|
|
|
old_relnum++;
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
new_relnum++;
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
if (!all_matched)
|
|
|
|
pg_fatal("Failed to match up old and new tables in database \"%s\"\n",
|
2014-05-06 18:12:18 +02:00
|
|
|
old_db->db_name);
|
2012-10-02 17:53:45 +02:00
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
*nmaps = num_maps;
|
|
|
|
return maps;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2011-01-05 01:11:00 +01:00
|
|
|
* create_rel_filename_map()
|
2010-05-12 04:19:11 +02:00
|
|
|
*
|
|
|
|
* fills a file node map structure and returns it in "map".
|
|
|
|
*/
|
|
|
|
static void
|
2011-01-05 01:11:00 +01:00
|
|
|
create_rel_filename_map(const char *old_data, const char *new_data,
|
2011-04-10 17:42:00 +02:00
|
|
|
const DbInfo *old_db, const DbInfo *new_db,
|
|
|
|
const RelInfo *old_rel, const RelInfo *new_rel,
|
|
|
|
FileNameMap *map)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2015-09-11 21:51:11 +02:00
|
|
|
/* In case old/new tablespaces don't match, do them separately. */
|
2011-01-05 01:11:00 +01:00
|
|
|
if (strlen(old_rel->tablespace) == 0)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
/*
|
2011-01-05 01:11:00 +01:00
|
|
|
* relation belongs to the default tablespace, hence relfiles should
|
2010-05-12 04:19:11 +02:00
|
|
|
* exist in the data directories.
|
|
|
|
*/
|
2014-02-12 22:35:24 +01:00
|
|
|
map->old_tablespace = old_data;
|
|
|
|
map->old_tablespace_suffix = "/base";
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2011-01-05 17:37:08 +01:00
|
|
|
/* relation belongs to a tablespace, so use the tablespace location */
|
2014-02-12 22:35:24 +01:00
|
|
|
map->old_tablespace = old_rel->tablespace;
|
|
|
|
map->old_tablespace_suffix = old_cluster.tablespace_suffix;
|
2015-09-11 21:51:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Do the same for new tablespaces */
|
|
|
|
if (strlen(new_rel->tablespace) == 0)
|
|
|
|
{
|
|
|
|
map->new_tablespace = new_data;
|
|
|
|
map->new_tablespace_suffix = "/base";
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
map->new_tablespace = new_rel->tablespace;
|
2014-02-12 22:35:24 +01:00
|
|
|
map->new_tablespace_suffix = new_cluster.tablespace_suffix;
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
2011-01-05 17:37:08 +01:00
|
|
|
|
2013-01-09 14:57:47 +01:00
|
|
|
map->old_db_oid = old_db->db_oid;
|
|
|
|
map->new_db_oid = new_db->db_oid;
|
|
|
|
|
2011-01-08 04:57:30 +01:00
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* old_relfilenode might differ from pg_class.oid (and hence
|
|
|
|
* new_relfilenode) because of CLUSTER, REINDEX, or VACUUM FULL.
|
2011-01-08 04:57:30 +01:00
|
|
|
*/
|
2011-01-05 17:37:08 +01:00
|
|
|
map->old_relfilenode = old_rel->relfilenode;
|
2011-01-08 04:57:30 +01:00
|
|
|
|
|
|
|
/* new_relfilenode will match old and new pg_class.oid */
|
2011-01-05 17:37:08 +01:00
|
|
|
map->new_relfilenode = new_rel->relfilenode;
|
|
|
|
|
2011-01-08 04:36:51 +01:00
|
|
|
/* used only for logging and error reporing, old/new are identical */
|
2012-12-20 19:56:24 +01:00
|
|
|
map->nspname = old_rel->nspname;
|
|
|
|
map->relname = old_rel->relname;
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/*
|
|
|
|
* Complain about a relation we couldn't match to the other database,
|
|
|
|
* identifying it as best we can.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
report_unmatched_relation(const RelInfo *rel, const DbInfo *db, bool is_new_db)
|
|
|
|
{
|
|
|
|
Oid reloid = rel->reloid; /* we might change rel below */
|
|
|
|
char reldesc[1000];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
snprintf(reldesc, sizeof(reldesc), "\"%s.%s\"",
|
|
|
|
rel->nspname, rel->relname);
|
|
|
|
if (rel->indtable)
|
|
|
|
{
|
|
|
|
for (i = 0; i < db->rel_arr.nrels; i++)
|
|
|
|
{
|
|
|
|
const RelInfo *hrel = &db->rel_arr.rels[i];
|
|
|
|
|
|
|
|
if (hrel->reloid == rel->indtable)
|
|
|
|
{
|
|
|
|
snprintf(reldesc + strlen(reldesc),
|
|
|
|
sizeof(reldesc) - strlen(reldesc),
|
2016-10-14 18:00:00 +02:00
|
|
|
_(" which is an index on \"%s.%s\""),
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
hrel->nspname, hrel->relname);
|
|
|
|
/* Shift attention to index's table for toast check */
|
|
|
|
rel = hrel;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (i >= db->rel_arr.nrels)
|
|
|
|
snprintf(reldesc + strlen(reldesc),
|
|
|
|
sizeof(reldesc) - strlen(reldesc),
|
2016-10-14 18:00:00 +02:00
|
|
|
_(" which is an index on OID %u"), rel->indtable);
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
}
|
|
|
|
if (rel->toastheap)
|
|
|
|
{
|
|
|
|
for (i = 0; i < db->rel_arr.nrels; i++)
|
|
|
|
{
|
|
|
|
const RelInfo *brel = &db->rel_arr.rels[i];
|
|
|
|
|
|
|
|
if (brel->reloid == rel->toastheap)
|
|
|
|
{
|
|
|
|
snprintf(reldesc + strlen(reldesc),
|
|
|
|
sizeof(reldesc) - strlen(reldesc),
|
2016-10-14 18:00:00 +02:00
|
|
|
_(" which is the TOAST table for \"%s.%s\""),
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
brel->nspname, brel->relname);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (i >= db->rel_arr.nrels)
|
|
|
|
snprintf(reldesc + strlen(reldesc),
|
|
|
|
sizeof(reldesc) - strlen(reldesc),
|
2016-10-14 18:00:00 +02:00
|
|
|
_(" which is the TOAST table for OID %u"), rel->toastheap);
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (is_new_db)
|
|
|
|
pg_log(PG_WARNING, "No match found in old cluster for new relation with OID %u in database \"%s\": %s\n",
|
|
|
|
reloid, db->db_name, reldesc);
|
|
|
|
else
|
|
|
|
pg_log(PG_WARNING, "No match found in new cluster for old relation with OID %u in database \"%s\": %s\n",
|
|
|
|
reloid, db->db_name, reldesc);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
void
|
2011-01-10 17:45:22 +01:00
|
|
|
print_maps(FileNameMap *maps, int n_maps, const char *db_name)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2012-03-13 00:47:54 +01:00
|
|
|
if (log_opts.verbose)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
int mapnum;
|
|
|
|
|
2012-03-13 00:47:54 +01:00
|
|
|
pg_log(PG_VERBOSE, "mappings for database \"%s\":\n", db_name);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2011-01-10 17:45:22 +01:00
|
|
|
for (mapnum = 0; mapnum < n_maps; mapnum++)
|
2012-03-13 00:47:54 +01:00
|
|
|
pg_log(PG_VERBOSE, "%s.%s: %u to %u\n",
|
2011-01-08 04:36:51 +01:00
|
|
|
maps[mapnum].nspname, maps[mapnum].relname,
|
2010-10-20 00:37:04 +02:00
|
|
|
maps[mapnum].old_relfilenode,
|
|
|
|
maps[mapnum].new_relfilenode);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2012-03-13 00:47:54 +01:00
|
|
|
pg_log(PG_VERBOSE, "\n\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-01-10 17:45:22 +01:00
|
|
|
/*
|
|
|
|
* get_db_and_rel_infos()
|
|
|
|
*
|
|
|
|
* higher level routine to generate dbinfos for the database running
|
|
|
|
* on the given "port". Assumes that server is already running.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
get_db_and_rel_infos(ClusterInfo *cluster)
|
|
|
|
{
|
|
|
|
int dbnum;
|
|
|
|
|
2011-02-16 01:01:33 +01:00
|
|
|
if (cluster->dbarr.dbs != NULL)
|
|
|
|
free_db_and_rel_infos(&cluster->dbarr);
|
2011-02-15 21:00:07 +01:00
|
|
|
|
2011-01-10 17:45:22 +01:00
|
|
|
get_db_infos(cluster);
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
get_rel_infos(cluster, &cluster->dbarr.dbs[dbnum]);
|
|
|
|
|
2012-03-13 00:47:54 +01:00
|
|
|
pg_log(PG_VERBOSE, "\n%s databases:\n", CLUSTER_NAME(cluster));
|
|
|
|
if (log_opts.verbose)
|
2011-01-10 17:45:22 +01:00
|
|
|
print_db_infos(&cluster->dbarr);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
/*
|
|
|
|
* get_db_infos()
|
|
|
|
*
|
2011-01-01 18:06:36 +01:00
|
|
|
* Scans pg_database system catalog and populates all user
|
2010-05-12 04:19:11 +02:00
|
|
|
* databases.
|
|
|
|
*/
|
|
|
|
static void
|
2011-01-01 18:06:36 +01:00
|
|
|
get_db_infos(ClusterInfo *cluster)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2011-01-01 18:06:36 +01:00
|
|
|
PGconn *conn = connectToServer(cluster, "template1");
|
2010-05-12 04:19:11 +02:00
|
|
|
PGresult *res;
|
|
|
|
int ntups;
|
|
|
|
int tupnum;
|
|
|
|
DbInfo *dbinfos;
|
2011-04-10 17:42:00 +02:00
|
|
|
int i_datname,
|
|
|
|
i_oid,
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
i_encoding,
|
|
|
|
i_datcollate,
|
|
|
|
i_datctype,
|
2011-04-10 17:42:00 +02:00
|
|
|
i_spclocation;
|
2011-12-07 10:35:00 +01:00
|
|
|
char query[QUERY_ALLOC];
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2011-12-07 10:35:00 +01:00
|
|
|
snprintf(query, sizeof(query),
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
"SELECT d.oid, d.datname, d.encoding, d.datcollate, d.datctype, "
|
|
|
|
"%s AS spclocation "
|
2012-06-10 21:20:04 +02:00
|
|
|
"FROM pg_catalog.pg_database d "
|
|
|
|
" LEFT OUTER JOIN pg_catalog.pg_tablespace t "
|
|
|
|
" ON d.dattablespace = t.oid "
|
|
|
|
"WHERE d.datallowconn = true "
|
2011-01-08 19:44:44 +01:00
|
|
|
/* we don't preserve pg_database.oid so we sort by name */
|
2012-06-10 21:20:04 +02:00
|
|
|
"ORDER BY 2",
|
2011-12-07 10:35:00 +01:00
|
|
|
/* 9.2 removed the spclocation column */
|
2012-06-10 21:20:04 +02:00
|
|
|
(GET_MAJOR_VERSION(cluster->major_version) <= 901) ?
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
"t.spclocation" : "pg_catalog.pg_tablespace_location(t.oid)");
|
2011-12-07 10:35:00 +01:00
|
|
|
|
|
|
|
res = executeQueryOrDie(conn, "%s", query);
|
2010-07-06 21:19:02 +02:00
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
i_oid = PQfnumber(res, "oid");
|
2011-03-06 02:18:31 +01:00
|
|
|
i_datname = PQfnumber(res, "datname");
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
i_encoding = PQfnumber(res, "encoding");
|
|
|
|
i_datcollate = PQfnumber(res, "datcollate");
|
|
|
|
i_datctype = PQfnumber(res, "datctype");
|
2010-05-12 04:19:11 +02:00
|
|
|
i_spclocation = PQfnumber(res, "spclocation");
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
2010-10-19 23:38:16 +02:00
|
|
|
dbinfos = (DbInfo *) pg_malloc(sizeof(DbInfo) * ntups);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
for (tupnum = 0; tupnum < ntups; tupnum++)
|
|
|
|
{
|
2010-09-29 00:11:17 +02:00
|
|
|
dbinfos[tupnum].db_oid = atooid(PQgetvalue(res, tupnum, i_oid));
|
2012-12-20 19:56:24 +01:00
|
|
|
dbinfos[tupnum].db_name = pg_strdup(PQgetvalue(res, tupnum, i_datname));
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
dbinfos[tupnum].db_encoding = atoi(PQgetvalue(res, tupnum, i_encoding));
|
|
|
|
dbinfos[tupnum].db_collate = pg_strdup(PQgetvalue(res, tupnum, i_datcollate));
|
|
|
|
dbinfos[tupnum].db_ctype = pg_strdup(PQgetvalue(res, tupnum, i_datctype));
|
2014-02-12 22:35:24 +01:00
|
|
|
snprintf(dbinfos[tupnum].db_tablespace, sizeof(dbinfos[tupnum].db_tablespace), "%s",
|
2010-05-12 04:19:11 +02:00
|
|
|
PQgetvalue(res, tupnum, i_spclocation));
|
|
|
|
}
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
2011-01-01 18:06:36 +01:00
|
|
|
cluster->dbarr.dbs = dbinfos;
|
|
|
|
cluster->dbarr.ndbs = ntups;
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get_rel_infos()
|
|
|
|
*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* gets the relinfos for all the user tables and indexes of the database
|
|
|
|
* referred to by "dbinfo".
|
2010-05-12 04:19:11 +02:00
|
|
|
*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* Note: the resulting RelInfo array is assumed to be sorted by OID.
|
|
|
|
* This allows later processing to match up old and new databases efficiently.
|
2010-05-12 04:19:11 +02:00
|
|
|
*/
|
|
|
|
static void
|
2011-01-05 01:11:00 +01:00
|
|
|
get_rel_infos(ClusterInfo *cluster, DbInfo *dbinfo)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2011-01-01 18:28:48 +01:00
|
|
|
PGconn *conn = connectToServer(cluster,
|
2011-01-05 01:11:00 +01:00
|
|
|
dbinfo->db_name);
|
2010-05-12 04:19:11 +02:00
|
|
|
PGresult *res;
|
|
|
|
RelInfo *relinfos;
|
|
|
|
int ntups;
|
|
|
|
int relnum;
|
|
|
|
int num_rels = 0;
|
|
|
|
char *nspname = NULL;
|
|
|
|
char *relname = NULL;
|
2014-02-12 22:35:24 +01:00
|
|
|
char *tablespace = NULL;
|
2011-04-10 17:42:00 +02:00
|
|
|
int i_spclocation,
|
|
|
|
i_nspname,
|
|
|
|
i_relname,
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
i_reloid,
|
|
|
|
i_indtable,
|
|
|
|
i_toastheap,
|
2012-04-11 01:57:14 +02:00
|
|
|
i_relfilenode,
|
|
|
|
i_reltablespace;
|
2010-05-12 04:19:11 +02:00
|
|
|
char query[QUERY_ALLOC];
|
2014-05-06 18:12:18 +02:00
|
|
|
char *last_namespace = NULL,
|
|
|
|
*last_tablespace = NULL;
|
2010-05-12 04:19:11 +02:00
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
query[0] = '\0'; /* initialize query string to empty */
|
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
/*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* Create a CTE that collects OIDs of regular user tables, including
|
|
|
|
* matviews and sequences, but excluding toast tables and indexes. We
|
|
|
|
* assume that relations with OIDs >= FirstNormalObjectId belong to the
|
|
|
|
* user. (That's probably redundant with the namespace-name exclusions,
|
|
|
|
* but let's be safe.)
|
|
|
|
*
|
2014-07-01 01:55:55 +02:00
|
|
|
* pg_largeobject contains user data that does not appear in pg_dump
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* output, so we have to copy that system table. It's easiest to do that
|
|
|
|
* by treating it as a user table. Likewise for pg_largeobject_metadata,
|
|
|
|
* if it exists.
|
2010-05-12 04:19:11 +02:00
|
|
|
*/
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
"WITH regular_heap (reloid, indtable, toastheap) AS ( "
|
|
|
|
" SELECT c.oid, 0::oid, 0::oid "
|
|
|
|
" FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n "
|
|
|
|
" ON c.relnamespace = n.oid "
|
2017-03-10 04:42:16 +01:00
|
|
|
" WHERE relkind IN (" CppAsString2(RELKIND_RELATION) ", "
|
|
|
|
CppAsString2(RELKIND_MATVIEW) ") AND "
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* exclude possible orphaned temp tables */
|
|
|
|
" ((n.nspname !~ '^pg_temp_' AND "
|
|
|
|
" n.nspname !~ '^pg_toast_temp_' AND "
|
|
|
|
" n.nspname NOT IN ('pg_catalog', 'information_schema', "
|
|
|
|
" 'binary_upgrade', 'pg_toast') AND "
|
|
|
|
" c.oid >= %u::pg_catalog.oid) OR "
|
|
|
|
" (n.nspname = 'pg_catalog' AND "
|
|
|
|
" relname IN ('pg_largeobject'%s) ))), ",
|
|
|
|
FirstNormalObjectId,
|
|
|
|
(GET_MAJOR_VERSION(old_cluster.major_version) >= 900) ?
|
|
|
|
", 'pg_largeobject_metadata'" : "");
|
2010-05-12 04:19:11 +02:00
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/*
|
|
|
|
* Add a CTE that collects OIDs of toast tables belonging to the tables
|
|
|
|
* selected by the regular_heap CTE. (We have to do this separately
|
|
|
|
* because the namespace-name rules above don't work for toast tables.)
|
|
|
|
*/
|
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
" toast_heap (reloid, indtable, toastheap) AS ( "
|
|
|
|
" SELECT c.reltoastrelid, 0::oid, c.oid "
|
|
|
|
" FROM regular_heap JOIN pg_catalog.pg_class c "
|
|
|
|
" ON regular_heap.reloid = c.oid "
|
|
|
|
" WHERE c.reltoastrelid != 0), ");
|
2015-05-24 03:35:49 +02:00
|
|
|
|
|
|
|
/*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* Add a CTE that collects OIDs of all valid indexes on the previously
|
|
|
|
* selected tables. We can ignore invalid indexes since pg_dump does.
|
|
|
|
* Testing indisready is necessary in 9.2, and harmless in earlier/later
|
|
|
|
* versions.
|
2015-05-24 03:35:49 +02:00
|
|
|
*/
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
" all_index (reloid, indtable, toastheap) AS ( "
|
|
|
|
" SELECT indexrelid, indrelid, 0::oid "
|
|
|
|
" FROM pg_catalog.pg_index "
|
|
|
|
" WHERE indisvalid AND indisready "
|
|
|
|
" AND indrelid IN "
|
|
|
|
" (SELECT reloid FROM regular_heap "
|
|
|
|
" UNION ALL "
|
|
|
|
" SELECT reloid FROM toast_heap)) ");
|
2015-05-24 03:35:49 +02:00
|
|
|
|
|
|
|
/*
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
* And now we can write the query that retrieves the data we want for each
|
|
|
|
* heap and index relation. Make sure result is sorted by OID.
|
2015-05-24 03:35:49 +02:00
|
|
|
*/
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
"SELECT all_rels.*, n.nspname, c.relname, "
|
|
|
|
" c.relfilenode, c.reltablespace, %s "
|
|
|
|
"FROM (SELECT * FROM regular_heap "
|
|
|
|
" UNION ALL "
|
|
|
|
" SELECT * FROM toast_heap "
|
|
|
|
" UNION ALL "
|
|
|
|
" SELECT * FROM all_index) all_rels "
|
2015-05-24 03:35:49 +02:00
|
|
|
" JOIN pg_catalog.pg_class c "
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
" ON all_rels.reloid = c.oid "
|
2015-05-24 03:35:49 +02:00
|
|
|
" JOIN pg_catalog.pg_namespace n "
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
" ON c.relnamespace = n.oid "
|
2015-05-24 03:35:49 +02:00
|
|
|
" LEFT OUTER JOIN pg_catalog.pg_tablespace t "
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
" ON c.reltablespace = t.oid "
|
2015-05-24 03:35:49 +02:00
|
|
|
"ORDER BY 1;",
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* 9.2 removed the pg_tablespace.spclocation column */
|
|
|
|
(GET_MAJOR_VERSION(cluster->major_version) >= 902) ?
|
|
|
|
"pg_catalog.pg_tablespace_location(t.oid) AS spclocation" :
|
|
|
|
"t.spclocation");
|
2012-10-02 17:46:08 +02:00
|
|
|
|
2011-09-10 22:12:46 +02:00
|
|
|
res = executeQueryOrDie(conn, "%s", query);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
relinfos = (RelInfo *) pg_malloc(sizeof(RelInfo) * ntups);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
i_reloid = PQfnumber(res, "reloid");
|
|
|
|
i_indtable = PQfnumber(res, "indtable");
|
|
|
|
i_toastheap = PQfnumber(res, "toastheap");
|
2010-05-12 04:19:11 +02:00
|
|
|
i_nspname = PQfnumber(res, "nspname");
|
|
|
|
i_relname = PQfnumber(res, "relname");
|
|
|
|
i_relfilenode = PQfnumber(res, "relfilenode");
|
2012-04-11 01:57:14 +02:00
|
|
|
i_reltablespace = PQfnumber(res, "reltablespace");
|
2010-05-12 04:19:11 +02:00
|
|
|
i_spclocation = PQfnumber(res, "spclocation");
|
|
|
|
|
|
|
|
for (relnum = 0; relnum < ntups; relnum++)
|
|
|
|
{
|
|
|
|
RelInfo *curr = &relinfos[num_rels++];
|
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
curr->reloid = atooid(PQgetvalue(res, relnum, i_reloid));
|
|
|
|
curr->indtable = atooid(PQgetvalue(res, relnum, i_indtable));
|
|
|
|
curr->toastheap = atooid(PQgetvalue(res, relnum, i_toastheap));
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
nspname = PQgetvalue(res, relnum, i_nspname);
|
2014-02-12 22:35:24 +01:00
|
|
|
curr->nsp_alloc = false;
|
|
|
|
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Many of the namespace and tablespace strings are identical, so we
|
|
|
|
* try to reuse the allocated string pointers where possible to reduce
|
|
|
|
* memory consumption.
|
2014-02-12 22:35:24 +01:00
|
|
|
*/
|
|
|
|
/* Can we reuse the previous string allocation? */
|
|
|
|
if (last_namespace && strcmp(nspname, last_namespace) == 0)
|
|
|
|
curr->nspname = last_namespace;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
last_namespace = curr->nspname = pg_strdup(nspname);
|
|
|
|
curr->nsp_alloc = true;
|
|
|
|
}
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
relname = PQgetvalue(res, relnum, i_relname);
|
2012-12-20 19:56:24 +01:00
|
|
|
curr->relname = pg_strdup(relname);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2010-09-29 00:11:17 +02:00
|
|
|
curr->relfilenode = atooid(PQgetvalue(res, relnum, i_relfilenode));
|
2014-02-12 22:35:24 +01:00
|
|
|
curr->tblsp_alloc = false;
|
2010-05-12 04:19:11 +02:00
|
|
|
|
Improve pg_upgrade's report about failure to match up old and new tables.
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all
the relations it sees in the old and new databases. If it does, however,
it just goes belly-up with a pretty unhelpful error message. That seemed
fine as long as we expected the case never to occur in the wild, but
Alvaro reported that it had been seen in a database whose pg_largeobject
table had somehow acquired a TOAST table. That doesn't quite seem like
a case that pg_upgrade actually needs to handle, but it would be good if
the report were more diagnosable. Hence, extend the logic to print out
as much information as we can about the mismatch(es) before we quit.
In passing, improve the readability of get_rel_infos()'s data collection
query, which had suffered seriously from lets-not-bother-to-update-comments
syndrome, and generally was unnecessarily disrespectful to readers.
It could be argued that this is a bug fix, but given that we have so few
reports, I don't feel a need to back-patch; at least not before this has
baked awhile in HEAD.
2016-05-06 20:23:45 +02:00
|
|
|
/* Is the tablespace oid non-default? */
|
2012-04-11 01:57:14 +02:00
|
|
|
if (atooid(PQgetvalue(res, relnum, i_reltablespace)) != 0)
|
2014-02-12 22:35:24 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The tablespace location might be "", meaning the cluster
|
|
|
|
* default location, i.e. pg_default or pg_global.
|
|
|
|
*/
|
|
|
|
tablespace = PQgetvalue(res, relnum, i_spclocation);
|
|
|
|
|
|
|
|
/* Can we reuse the previous string allocation? */
|
|
|
|
if (last_tablespace && strcmp(tablespace, last_tablespace) == 0)
|
|
|
|
curr->tablespace = last_tablespace;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
last_tablespace = curr->tablespace = pg_strdup(tablespace);
|
|
|
|
curr->tblsp_alloc = true;
|
|
|
|
}
|
|
|
|
}
|
2012-04-11 01:57:14 +02:00
|
|
|
else
|
2014-02-12 22:35:24 +01:00
|
|
|
/* A zero reltablespace oid indicates the database tablespace. */
|
|
|
|
curr->tablespace = dbinfo->db_tablespace;
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
2011-01-05 01:11:00 +01:00
|
|
|
dbinfo->rel_arr.rels = relinfos;
|
|
|
|
dbinfo->rel_arr.nrels = num_rels;
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-11-14 03:10:40 +01:00
|
|
|
static void
|
2011-01-10 17:45:22 +01:00
|
|
|
free_db_and_rel_infos(DbInfoArr *db_arr)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
int dbnum;
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < db_arr->ndbs; dbnum++)
|
2012-12-20 19:56:24 +01:00
|
|
|
{
|
2011-01-10 17:45:22 +01:00
|
|
|
free_rel_infos(&db_arr->dbs[dbnum].rel_arr);
|
2012-12-20 19:56:24 +01:00
|
|
|
pg_free(db_arr->dbs[dbnum].db_name);
|
|
|
|
}
|
2011-01-10 17:45:22 +01:00
|
|
|
pg_free(db_arr->dbs);
|
2011-02-16 01:01:33 +01:00
|
|
|
db_arr->dbs = NULL;
|
2010-05-12 04:19:11 +02:00
|
|
|
db_arr->ndbs = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
2011-01-10 17:45:22 +01:00
|
|
|
free_rel_infos(RelInfoArr *rel_arr)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2012-12-20 19:56:24 +01:00
|
|
|
int relnum;
|
|
|
|
|
|
|
|
for (relnum = 0; relnum < rel_arr->nrels; relnum++)
|
|
|
|
{
|
2014-02-12 22:35:24 +01:00
|
|
|
if (rel_arr->rels[relnum].nsp_alloc)
|
|
|
|
pg_free(rel_arr->rels[relnum].nspname);
|
2012-12-20 19:56:24 +01:00
|
|
|
pg_free(rel_arr->rels[relnum].relname);
|
2014-02-12 22:35:24 +01:00
|
|
|
if (rel_arr->rels[relnum].tblsp_alloc)
|
|
|
|
pg_free(rel_arr->rels[relnum].tablespace);
|
2012-12-20 19:56:24 +01:00
|
|
|
}
|
2011-01-10 17:45:22 +01:00
|
|
|
pg_free(rel_arr->rels);
|
|
|
|
rel_arr->nrels = 0;
|
|
|
|
}
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
2011-01-10 17:45:22 +01:00
|
|
|
static void
|
|
|
|
print_db_infos(DbInfoArr *db_arr)
|
|
|
|
{
|
|
|
|
int dbnum;
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < db_arr->ndbs; dbnum++)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2012-03-13 00:47:54 +01:00
|
|
|
pg_log(PG_VERBOSE, "Database: %s\n", db_arr->dbs[dbnum].db_name);
|
2011-01-10 17:45:22 +01:00
|
|
|
print_rel_infos(&db_arr->dbs[dbnum].rel_arr);
|
2012-03-13 00:47:54 +01:00
|
|
|
pg_log(PG_VERBOSE, "\n\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
2012-12-20 19:56:24 +01:00
|
|
|
print_rel_infos(RelInfoArr *rel_arr)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
int relnum;
|
|
|
|
|
2012-12-20 19:56:24 +01:00
|
|
|
for (relnum = 0; relnum < rel_arr->nrels; relnum++)
|
2012-03-13 00:47:54 +01:00
|
|
|
pg_log(PG_VERBOSE, "relname: %s.%s: reloid: %u reltblspace: %s\n",
|
2013-06-01 15:38:15 +02:00
|
|
|
rel_arr->rels[relnum].nspname,
|
|
|
|
rel_arr->rels[relnum].relname,
|
|
|
|
rel_arr->rels[relnum].reloid,
|
|
|
|
rel_arr->rels[relnum].tablespace);
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|