|
|
|
|
/*
|
|
|
|
|
* info.c
|
|
|
|
|
*
|
|
|
|
|
* information support functions
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2010-2023, PostgreSQL Global Development Group
|
|
|
|
|
* src/bin/pg_upgrade/info.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 "access/transam.h"
|
|
|
|
|
#include "catalog/pg_class_d.h"
|
|
|
|
|
#include "pg_upgrade.h"
|
|
|
|
|
|
|
|
|
|
static void create_rel_filename_map(const char *old_data, const char *new_data,
|
|
|
|
|
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.
10 years ago
|
|
|
static void report_unmatched_relation(const RelInfo *rel, const DbInfo *db,
|
|
|
|
|
bool is_new_db);
|
|
|
|
|
static void free_db_and_rel_infos(DbInfoArr *db_arr);
|
|
|
|
|
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 *db_arr);
|
|
|
|
|
static void print_rel_infos(RelInfoArr *rel_arr);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
10 years ago
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
FileNameMap *
|
|
|
|
|
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.
10 years ago
|
|
|
int *nmaps,
|
|
|
|
|
const char *old_pgdata, const char *new_pgdata)
|
|
|
|
|
{
|
|
|
|
|
FileNameMap *maps;
|
|
|
|
|
int old_relnum,
|
|
|
|
|
new_relnum;
|
|
|
|
|
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.
10 years ago
|
|
|
bool all_matched = true;
|
|
|
|
|
|
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.
10 years ago
|
|
|
/* There will certainly not be more mappings than there are old rels */
|
|
|
|
|
maps = (FileNameMap *) pg_malloc(sizeof(FileNameMap) *
|
|
|
|
|
old_db->rel_arr.nrels);
|
|
|
|
|
|
|
|
|
|
/*
|
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.
10 years ago
|
|
|
* 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.
|
|
|
|
|
*/
|
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.
10 years ago
|
|
|
old_relnum = new_relnum = 0;
|
|
|
|
|
while (old_relnum < old_db->rel_arr.nrels ||
|
|
|
|
|
new_relnum < new_db->rel_arr.nrels)
|
|
|
|
|
{
|
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.
10 years ago
|
|
|
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;
|
|
|
|
|
|
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.
10 years ago
|
|
|
/* handle running off one array before the other */
|
|
|
|
|
if (!new_rel)
|
|
|
|
|
{
|
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.
10 years ago
|
|
|
/*
|
|
|
|
|
* 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;
|
|
|
|
|
}
|
|
|
|
|
|
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.
10 years ago
|
|
|
/* check for mismatched OID */
|
|
|
|
|
if (old_rel->reloid < new_rel->reloid)
|
|
|
|
|
{
|
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.
10 years ago
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
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.
10 years ago
|
|
|
* 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).
|
|
|
|
|
*/
|
|
|
|
|
if (strcmp(old_rel->nspname, new_rel->nspname) != 0 ||
|
|
|
|
|
strcmp(old_rel->relname, new_rel->relname) != 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.
10 years ago
|
|
|
{
|
|
|
|
|
pg_log(PG_WARNING, "Relation names for OID %u in database \"%s\" do not match: "
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
"old name \"%s.%s\", new name \"%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.
10 years ago
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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.
10 years ago
|
|
|
/* OK, create a mapping entry */
|
|
|
|
|
create_rel_filename_map(old_pgdata, new_pgdata, old_db, new_db,
|
|
|
|
|
old_rel, new_rel, maps + num_maps);
|
|
|
|
|
num_maps++;
|
|
|
|
|
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.
10 years ago
|
|
|
new_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.
10 years ago
|
|
|
if (!all_matched)
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
pg_fatal("Failed to match up old and new tables in database \"%s\"",
|
|
|
|
|
old_db->db_name);
|
|
|
|
|
|
|
|
|
|
*nmaps = num_maps;
|
|
|
|
|
return maps;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* create_rel_filename_map()
|
|
|
|
|
*
|
|
|
|
|
* fills a file node map structure and returns it in "map".
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
create_rel_filename_map(const char *old_data, const char *new_data,
|
|
|
|
|
const DbInfo *old_db, const DbInfo *new_db,
|
|
|
|
|
const RelInfo *old_rel, const RelInfo *new_rel,
|
|
|
|
|
FileNameMap *map)
|
|
|
|
|
{
|
|
|
|
|
/* In case old/new tablespaces don't match, do them separately. */
|
|
|
|
|
if (strlen(old_rel->tablespace) == 0)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* relation belongs to the default tablespace, hence relfiles should
|
|
|
|
|
* exist in the data directories.
|
|
|
|
|
*/
|
|
|
|
|
map->old_tablespace = old_data;
|
|
|
|
|
map->old_tablespace_suffix = "/base";
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* relation belongs to a tablespace, so use the tablespace location */
|
|
|
|
|
map->old_tablespace = old_rel->tablespace;
|
|
|
|
|
map->old_tablespace_suffix = old_cluster.tablespace_suffix;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
|
map->new_tablespace_suffix = new_cluster.tablespace_suffix;
|
|
|
|
|
}
|
|
|
|
|
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
4 years ago
|
|
|
/* DB oid and relfilenumbers are preserved between old and new cluster */
|
pg_upgrade: Preserve database OIDs.
Commit 9a974cbcba005256a19991203583a94b4f9a21a9 arranged to preserve
relfilenodes and tablespace OIDs. For similar reasons, also arrange
to preserve database OIDs.
One problem is that, up until now, the OIDs assigned to the template0
and postgres databases have not been fixed. This could be a problem
when upgrading, because pg_upgrade might try to migrate a database
from the old cluster to the new cluster while keeping the OID and find
a different database with that OID, resulting in a failure. If it finds
a database with the same name and the same OID that's OK: it will be
dropped and recreated. But the same OID and a different name is a
problem.
To prevent that, fix the OIDs for postgres and template0 to specific
values less than 16384. To avoid running afoul of this rule, these
values should not be changed in future releases. It's not a problem
that these OIDs aren't fixed in existing releases, because the OIDs
that we're assigning here weren't used for either of these databases
in any previous release. Thus, there's no chance that an upgrade of
a cluster from any previous release will collide with the OIDs we're
assigning here. And going forward, the OIDs will always be fixed, so
the only potential collision is with a system database having the
same name and the same OID, which is OK.
This patch lets users assign a specific OID to a database as well,
provided however that it can't be less than 16384. I (rhaas) thought
it might be better not to expose this capability to users, but the
consensus was otherwise, so the syntax is documented. Letting users
assign OIDs below 16384 would not be OK, though, because a
user-created database with a low-numbered OID might collide with a
system-created database in a future release. We therefore prohibit
that.
Shruthi KC, based on an earlier patch from Antonin Houska, reviewed
and with some adjustments by me.
Discussion: http://postgr.es/m/CA+TgmoYgTwYcUmB=e8+hRHOFA0kkS6Kde85+UNdon6q7bt1niQ@mail.gmail.com
Discussion: http://postgr.es/m/CAASxf_Mnwm1Dh2vd5FAhVX6S1nwNSZUB1z12VddYtM++H2+p7w@mail.gmail.com
4 years ago
|
|
|
map->db_oid = old_db->db_oid;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
4 years ago
|
|
|
map->relfilenumber = old_rel->relfilenumber;
|
|
|
|
|
|
|
|
|
|
/* used only for logging and error reporting, old/new are identical */
|
|
|
|
|
map->nspname = old_rel->nspname;
|
|
|
|
|
map->relname = old_rel->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.
10 years ago
|
|
|
/*
|
|
|
|
|
* 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),
|
|
|
|
|
_(" 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.
10 years ago
|
|
|
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),
|
|
|
|
|
_(" 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.
10 years ago
|
|
|
}
|
|
|
|
|
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),
|
|
|
|
|
_(" 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.
10 years ago
|
|
|
brel->nspname, brel->relname);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (i >= db->rel_arr.nrels)
|
|
|
|
|
snprintf(reldesc + strlen(reldesc),
|
|
|
|
|
sizeof(reldesc) - strlen(reldesc),
|
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
9 years ago
|
|
|
_(" 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.
10 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (is_new_db)
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
pg_log(PG_WARNING, "No match found in old cluster for new relation with OID %u in database \"%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.
10 years ago
|
|
|
reloid, db->db_name, reldesc);
|
|
|
|
|
else
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
pg_log(PG_WARNING, "No match found in new cluster for old relation with OID %u in database \"%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.
10 years ago
|
|
|
reloid, db->db_name, reldesc);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
|
|
if (cluster->dbarr.dbs != NULL)
|
|
|
|
|
free_db_and_rel_infos(&cluster->dbarr);
|
|
|
|
|
|
|
|
|
|
get_db_infos(cluster);
|
|
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
|
get_rel_infos(cluster, &cluster->dbarr.dbs[dbnum]);
|
|
|
|
|
|
|
|
|
|
if (cluster == &old_cluster)
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
pg_log(PG_VERBOSE, "\nsource databases:");
|
|
|
|
|
else
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
pg_log(PG_VERBOSE, "\ntarget databases:");
|
|
|
|
|
|
|
|
|
|
if (log_opts.verbose)
|
|
|
|
|
print_db_infos(&cluster->dbarr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* get_db_infos()
|
|
|
|
|
*
|
|
|
|
|
* Scans pg_database system catalog and populates all user
|
|
|
|
|
* databases.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
get_db_infos(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
PGconn *conn = connectToServer(cluster, "template1");
|
|
|
|
|
PGresult *res;
|
|
|
|
|
int ntups;
|
|
|
|
|
int tupnum;
|
|
|
|
|
DbInfo *dbinfos;
|
|
|
|
|
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.
11 years ago
|
|
|
i_encoding,
|
|
|
|
|
i_datcollate,
|
|
|
|
|
i_datctype,
|
|
|
|
|
i_datlocprovider,
|
|
|
|
|
i_daticulocale,
|
|
|
|
|
i_spclocation;
|
|
|
|
|
char query[QUERY_ALLOC];
|
|
|
|
|
|
|
|
|
|
snprintf(query, sizeof(query),
|
|
|
|
|
"SELECT d.oid, d.datname, d.encoding, d.datcollate, d.datctype, ");
|
|
|
|
|
if (GET_MAJOR_VERSION(cluster->major_version) < 1500)
|
|
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
|
"'c' AS datlocprovider, NULL AS daticulocale, ");
|
|
|
|
|
else
|
|
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
|
"datlocprovider, daticulocale, ");
|
|
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
|
"pg_catalog.pg_tablespace_location(t.oid) AS spclocation "
|
|
|
|
|
"FROM pg_catalog.pg_database d "
|
|
|
|
|
" LEFT OUTER JOIN pg_catalog.pg_tablespace t "
|
|
|
|
|
" ON d.dattablespace = t.oid "
|
|
|
|
|
"WHERE d.datallowconn = true "
|
pg_upgrade: Preserve database OIDs.
Commit 9a974cbcba005256a19991203583a94b4f9a21a9 arranged to preserve
relfilenodes and tablespace OIDs. For similar reasons, also arrange
to preserve database OIDs.
One problem is that, up until now, the OIDs assigned to the template0
and postgres databases have not been fixed. This could be a problem
when upgrading, because pg_upgrade might try to migrate a database
from the old cluster to the new cluster while keeping the OID and find
a different database with that OID, resulting in a failure. If it finds
a database with the same name and the same OID that's OK: it will be
dropped and recreated. But the same OID and a different name is a
problem.
To prevent that, fix the OIDs for postgres and template0 to specific
values less than 16384. To avoid running afoul of this rule, these
values should not be changed in future releases. It's not a problem
that these OIDs aren't fixed in existing releases, because the OIDs
that we're assigning here weren't used for either of these databases
in any previous release. Thus, there's no chance that an upgrade of
a cluster from any previous release will collide with the OIDs we're
assigning here. And going forward, the OIDs will always be fixed, so
the only potential collision is with a system database having the
same name and the same OID, which is OK.
This patch lets users assign a specific OID to a database as well,
provided however that it can't be less than 16384. I (rhaas) thought
it might be better not to expose this capability to users, but the
consensus was otherwise, so the syntax is documented. Letting users
assign OIDs below 16384 would not be OK, though, because a
user-created database with a low-numbered OID might collide with a
system-created database in a future release. We therefore prohibit
that.
Shruthi KC, based on an earlier patch from Antonin Houska, reviewed
and with some adjustments by me.
Discussion: http://postgr.es/m/CA+TgmoYgTwYcUmB=e8+hRHOFA0kkS6Kde85+UNdon6q7bt1niQ@mail.gmail.com
Discussion: http://postgr.es/m/CAASxf_Mnwm1Dh2vd5FAhVX6S1nwNSZUB1z12VddYtM++H2+p7w@mail.gmail.com
4 years ago
|
|
|
"ORDER BY 1");
|
|
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn, "%s", query);
|
|
|
|
|
|
|
|
|
|
i_oid = PQfnumber(res, "oid");
|
|
|
|
|
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.
11 years ago
|
|
|
i_encoding = PQfnumber(res, "encoding");
|
|
|
|
|
i_datcollate = PQfnumber(res, "datcollate");
|
|
|
|
|
i_datctype = PQfnumber(res, "datctype");
|
|
|
|
|
i_datlocprovider = PQfnumber(res, "datlocprovider");
|
|
|
|
|
i_daticulocale = PQfnumber(res, "daticulocale");
|
|
|
|
|
i_spclocation = PQfnumber(res, "spclocation");
|
|
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
dbinfos = (DbInfo *) pg_malloc(sizeof(DbInfo) * ntups);
|
|
|
|
|
|
|
|
|
|
for (tupnum = 0; tupnum < ntups; tupnum++)
|
|
|
|
|
{
|
|
|
|
|
dbinfos[tupnum].db_oid = atooid(PQgetvalue(res, tupnum, i_oid));
|
|
|
|
|
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.
11 years ago
|
|
|
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));
|
|
|
|
|
dbinfos[tupnum].db_collprovider = PQgetvalue(res, tupnum, i_datlocprovider)[0];
|
|
|
|
|
if (PQgetisnull(res, tupnum, i_daticulocale))
|
|
|
|
|
dbinfos[tupnum].db_iculocale = NULL;
|
|
|
|
|
else
|
|
|
|
|
dbinfos[tupnum].db_iculocale = pg_strdup(PQgetvalue(res, tupnum, i_daticulocale));
|
|
|
|
|
snprintf(dbinfos[tupnum].db_tablespace, sizeof(dbinfos[tupnum].db_tablespace), "%s",
|
|
|
|
|
PQgetvalue(res, tupnum, i_spclocation));
|
|
|
|
|
}
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
cluster->dbarr.dbs = dbinfos;
|
|
|
|
|
cluster->dbarr.ndbs = ntups;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
10 years ago
|
|
|
* gets the relinfos for all the user tables and indexes of the database
|
|
|
|
|
* referred to by "dbinfo".
|
|
|
|
|
*
|
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.
10 years ago
|
|
|
* Note: the resulting RelInfo array is assumed to be sorted by OID.
|
|
|
|
|
* This allows later processing to match up old and new databases efficiently.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
get_rel_infos(ClusterInfo *cluster, DbInfo *dbinfo)
|
|
|
|
|
{
|
|
|
|
|
PGconn *conn = connectToServer(cluster,
|
|
|
|
|
dbinfo->db_name);
|
|
|
|
|
PGresult *res;
|
|
|
|
|
RelInfo *relinfos;
|
|
|
|
|
int ntups;
|
|
|
|
|
int relnum;
|
|
|
|
|
int num_rels = 0;
|
|
|
|
|
char *nspname = NULL;
|
|
|
|
|
char *relname = NULL;
|
|
|
|
|
char *tablespace = NULL;
|
|
|
|
|
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.
10 years ago
|
|
|
i_reloid,
|
|
|
|
|
i_indtable,
|
|
|
|
|
i_toastheap,
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
4 years ago
|
|
|
i_relfilenumber,
|
|
|
|
|
i_reltablespace;
|
|
|
|
|
char query[QUERY_ALLOC];
|
|
|
|
|
char *last_namespace = NULL,
|
|
|
|
|
*last_tablespace = NULL;
|
|
|
|
|
|
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.
10 years ago
|
|
|
query[0] = '\0'; /* initialize query string to empty */
|
|
|
|
|
|
|
|
|
|
/*
|
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.
10 years ago
|
|
|
* 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.)
|
|
|
|
|
*
|
|
|
|
|
* 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.
10 years ago
|
|
|
* output, so we have to copy that system table. It's easiest to do that
|
|
|
|
|
* by treating it as a user table.
|
|
|
|
|
*/
|
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.
10 years ago
|
|
|
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 "
|
|
|
|
|
" 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.
10 years ago
|
|
|
/* 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') ))), ",
|
|
|
|
|
FirstNormalObjectId);
|
|
|
|
|
|
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.
10 years ago
|
|
|
/*
|
|
|
|
|
* 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), ");
|
|
|
|
|
|
|
|
|
|
/*
|
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.
10 years ago
|
|
|
* 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.
|
|
|
|
|
*/
|
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.
10 years ago
|
|
|
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)) ");
|
|
|
|
|
|
|
|
|
|
/*
|
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.
10 years ago
|
|
|
* 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.
|
|
|
|
|
*/
|
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.
10 years ago
|
|
|
snprintf(query + strlen(query), sizeof(query) - strlen(query),
|
|
|
|
|
"SELECT all_rels.*, n.nspname, c.relname, "
|
|
|
|
|
" c.relfilenode, c.reltablespace, "
|
|
|
|
|
" pg_catalog.pg_tablespace_location(t.oid) AS spclocation "
|
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.
10 years ago
|
|
|
"FROM (SELECT * FROM regular_heap "
|
|
|
|
|
" UNION ALL "
|
|
|
|
|
" SELECT * FROM toast_heap "
|
|
|
|
|
" UNION ALL "
|
|
|
|
|
" SELECT * FROM all_index) all_rels "
|
|
|
|
|
" 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.
10 years ago
|
|
|
" ON all_rels.reloid = c.oid "
|
|
|
|
|
" 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.
10 years ago
|
|
|
" ON c.relnamespace = n.oid "
|
|
|
|
|
" 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.
10 years ago
|
|
|
" ON c.reltablespace = t.oid "
|
|
|
|
|
"ORDER BY 1;");
|
|
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn, "%s", query);
|
|
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
|
|
|
|
|
relinfos = (RelInfo *) pg_malloc(sizeof(RelInfo) * ntups);
|
|
|
|
|
|
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.
10 years ago
|
|
|
i_reloid = PQfnumber(res, "reloid");
|
|
|
|
|
i_indtable = PQfnumber(res, "indtable");
|
|
|
|
|
i_toastheap = PQfnumber(res, "toastheap");
|
|
|
|
|
i_nspname = PQfnumber(res, "nspname");
|
|
|
|
|
i_relname = PQfnumber(res, "relname");
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
4 years ago
|
|
|
i_relfilenumber = PQfnumber(res, "relfilenode");
|
|
|
|
|
i_reltablespace = PQfnumber(res, "reltablespace");
|
|
|
|
|
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.
10 years ago
|
|
|
curr->reloid = atooid(PQgetvalue(res, relnum, i_reloid));
|
|
|
|
|
curr->indtable = atooid(PQgetvalue(res, relnum, i_indtable));
|
|
|
|
|
curr->toastheap = atooid(PQgetvalue(res, relnum, i_toastheap));
|
|
|
|
|
|
|
|
|
|
nspname = PQgetvalue(res, relnum, i_nspname);
|
|
|
|
|
curr->nsp_alloc = false;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Many of the namespace and tablespace strings are identical, so we
|
|
|
|
|
* try to reuse the allocated string pointers where possible to reduce
|
|
|
|
|
* memory consumption.
|
|
|
|
|
*/
|
|
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
relname = PQgetvalue(res, relnum, i_relname);
|
|
|
|
|
curr->relname = pg_strdup(relname);
|
|
|
|
|
|
|
|
|
|
curr->relfilenumber = atooid(PQgetvalue(res, relnum, i_relfilenumber));
|
|
|
|
|
curr->tblsp_alloc = false;
|
|
|
|
|
|
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.
10 years ago
|
|
|
/* Is the tablespace oid non-default? */
|
|
|
|
|
if (atooid(PQgetvalue(res, relnum, i_reltablespace)) != 0)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* 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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
/* A zero reltablespace oid indicates the database tablespace. */
|
|
|
|
|
curr->tablespace = dbinfo->db_tablespace;
|
|
|
|
|
}
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
dbinfo->rel_arr.rels = relinfos;
|
|
|
|
|
dbinfo->rel_arr.nrels = num_rels;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
free_db_and_rel_infos(DbInfoArr *db_arr)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < db_arr->ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
free_rel_infos(&db_arr->dbs[dbnum].rel_arr);
|
|
|
|
|
pg_free(db_arr->dbs[dbnum].db_name);
|
|
|
|
|
}
|
|
|
|
|
pg_free(db_arr->dbs);
|
|
|
|
|
db_arr->dbs = NULL;
|
|
|
|
|
db_arr->ndbs = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
free_rel_infos(RelInfoArr *rel_arr)
|
|
|
|
|
{
|
|
|
|
|
int relnum;
|
|
|
|
|
|
|
|
|
|
for (relnum = 0; relnum < rel_arr->nrels; relnum++)
|
|
|
|
|
{
|
|
|
|
|
if (rel_arr->rels[relnum].nsp_alloc)
|
|
|
|
|
pg_free(rel_arr->rels[relnum].nspname);
|
|
|
|
|
pg_free(rel_arr->rels[relnum].relname);
|
|
|
|
|
if (rel_arr->rels[relnum].tblsp_alloc)
|
|
|
|
|
pg_free(rel_arr->rels[relnum].tablespace);
|
|
|
|
|
}
|
|
|
|
|
pg_free(rel_arr->rels);
|
|
|
|
|
rel_arr->nrels = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
print_db_infos(DbInfoArr *db_arr)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < db_arr->ndbs; dbnum++)
|
|
|
|
|
{
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
pg_log(PG_VERBOSE, "Database: %s", db_arr->dbs[dbnum].db_name);
|
|
|
|
|
print_rel_infos(&db_arr->dbs[dbnum].rel_arr);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
print_rel_infos(RelInfoArr *rel_arr)
|
|
|
|
|
{
|
|
|
|
|
int relnum;
|
|
|
|
|
|
|
|
|
|
for (relnum = 0; relnum < rel_arr->nrels; relnum++)
|
Remove trailing newlines in pg_upgrade's message strings.
pg_upgrade does not use common/logging.c, which is unfortunate
but changing it to do so seems like more work than is justified.
However, we really need to make it work more like common/logging.c
in one respect: the latter expects supplied message strings to not
end with a newline, instead adding one internally. As it stands,
pg_upgrade's logging facilities expect a caller-supplied newline
in some cases and not others, which is already an invitation to bugs,
but the inconsistency with our other frontend code makes it worse.
There are already several places with missing or extra newlines,
and it's inevitable that there won't be more if we let this stand.
Hence, run around and get rid of all trailing newlines in message
strings, and add an Assert that there's not one, similar to the
existing Assert in common/logging.c. Adjust the logging functions
to supply a newline at the right places.
(Some of these strings also have a *leading* newline, which would
be a good thing to get rid of too; but this patch doesn't attempt
that.)
There are some consequent minor changes in output. The ones that
aren't outright bug fixes are generally removal of extra blank
lines that the original coding intentionally inserted. It didn't
seem worth being bug-compatible with that.
Patch by me, reviewed by Kyotaro Horiguchi and Peter Eisentraut
Discussion: https://postgr.es/m/113191.1655233060@sss.pgh.pa.us
3 years ago
|
|
|
pg_log(PG_VERBOSE, "relname: %s.%s: reloid: %u reltblspace: %s",
|
|
|
|
|
rel_arr->rels[relnum].nspname,
|
|
|
|
|
rel_arr->rels[relnum].relname,
|
|
|
|
|
rel_arr->rels[relnum].reloid,
|
|
|
|
|
rel_arr->rels[relnum].tablespace);
|
|
|
|
|
}
|
