|
|
|
|
/*
|
|
|
|
|
* check.c
|
|
|
|
|
*
|
|
|
|
|
* server checks and output routines
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2010-2022, PostgreSQL Global Development Group
|
|
|
|
|
* src/bin/pg_upgrade/check.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 "catalog/pg_authid_d.h"
|
|
|
|
|
#include "catalog/pg_collation.h"
|
|
|
|
|
#include "fe_utils/string_utils.h"
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
#include "mb/pg_wchar.h"
|
|
|
|
|
#include "pg_upgrade.h"
|
|
|
|
|
|
|
|
|
|
static void check_new_cluster_is_empty(void);
|
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
|
|
|
static void check_databases_are_compatible(void);
|
|
|
|
|
static void check_locale_and_encoding(DbInfo *olddb, DbInfo *newdb);
|
|
|
|
|
static bool equivalent_locale(int category, const char *loca, const char *locb);
|
|
|
|
|
static void check_is_install_user(ClusterInfo *cluster);
|
|
|
|
|
static void check_proper_datallowconn(ClusterInfo *cluster);
|
|
|
|
|
static void check_for_prepared_transactions(ClusterInfo *cluster);
|
|
|
|
|
static void check_for_isn_and_int8_passing_mismatch(ClusterInfo *cluster);
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
5 years ago
|
|
|
static void check_for_user_defined_postfix_ops(ClusterInfo *cluster);
|
|
|
|
|
static void check_for_incompatible_polymorphics(ClusterInfo *cluster);
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
static void check_for_tables_with_oids(ClusterInfo *cluster);
|
Fix some more omissions in pg_upgrade's tests for non-upgradable types.
Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges. However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c. (The division
of responsibility between those files is less than clear...)
In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable. It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.
To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
5 years ago
|
|
|
static void check_for_composite_data_type_usage(ClusterInfo *cluster);
|
|
|
|
|
static void check_for_reg_data_type_usage(ClusterInfo *cluster);
|
|
|
|
|
static void check_for_jsonb_9_4_usage(ClusterInfo *cluster);
|
|
|
|
|
static void check_for_pg_role_prefix(ClusterInfo *cluster);
|
|
|
|
|
static void check_for_new_tablespace_dir(ClusterInfo *new_cluster);
|
|
|
|
|
static void check_for_user_defined_encoding_conversions(ClusterInfo *cluster);
|
|
|
|
|
static char *get_canonical_locale_name(int category, const char *locale);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* fix_path_separator
|
|
|
|
|
* For non-Windows, just return the argument.
|
|
|
|
|
* For Windows convert any forward slash to a backslash
|
|
|
|
|
* such as is suitable for arguments to builtin commands
|
|
|
|
|
* like RMDIR and DEL.
|
|
|
|
|
*/
|
|
|
|
|
static char *
|
|
|
|
|
fix_path_separator(char *path)
|
|
|
|
|
{
|
|
|
|
|
#ifdef WIN32
|
|
|
|
|
|
|
|
|
|
char *result;
|
|
|
|
|
char *c;
|
|
|
|
|
|
|
|
|
|
result = pg_strdup(path);
|
|
|
|
|
|
|
|
|
|
for (c = result; *c != '\0'; c++)
|
|
|
|
|
if (*c == '/')
|
|
|
|
|
*c = '\\';
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
return path;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
output_check_banner(bool live_check)
|
|
|
|
|
{
|
|
|
|
|
if (user_opts.check && live_check)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT,
|
|
|
|
|
"Performing Consistency Checks on Old Live Server\n"
|
|
|
|
|
"------------------------------------------------\n");
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT,
|
|
|
|
|
"Performing Consistency Checks\n"
|
|
|
|
|
"-----------------------------\n");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
check_and_dump_old_cluster(bool live_check)
|
|
|
|
|
{
|
|
|
|
|
/* -- OLD -- */
|
|
|
|
|
|
|
|
|
|
if (!live_check)
|
|
|
|
|
start_postmaster(&old_cluster, true);
|
|
|
|
|
|
|
|
|
|
/* Extract a list of databases and tables from the old cluster */
|
|
|
|
|
get_db_and_rel_infos(&old_cluster);
|
|
|
|
|
|
|
|
|
|
init_tablespaces();
|
|
|
|
|
|
|
|
|
|
get_loadable_libraries();
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check for various failure cases
|
|
|
|
|
*/
|
|
|
|
|
check_is_install_user(&old_cluster);
|
|
|
|
|
check_proper_datallowconn(&old_cluster);
|
|
|
|
|
check_for_prepared_transactions(&old_cluster);
|
Fix some more omissions in pg_upgrade's tests for non-upgradable types.
Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges. However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c. (The division
of responsibility between those files is less than clear...)
In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable. It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.
To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
5 years ago
|
|
|
check_for_composite_data_type_usage(&old_cluster);
|
|
|
|
|
check_for_reg_data_type_usage(&old_cluster);
|
|
|
|
|
check_for_isn_and_int8_passing_mismatch(&old_cluster);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* PG 14 changed the function signature of encoding conversion functions.
|
|
|
|
|
* Conversions from older versions cannot be upgraded automatically
|
|
|
|
|
* because the user-defined functions used by the encoding conversions
|
|
|
|
|
* need to be changed to match the new signature.
|
|
|
|
|
*/
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1300)
|
|
|
|
|
check_for_user_defined_encoding_conversions(&old_cluster);
|
|
|
|
|
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
5 years ago
|
|
|
/*
|
|
|
|
|
* Pre-PG 14 allowed user defined postfix operators, which are not
|
|
|
|
|
* supported anymore. Verify there are none, iff applicable.
|
|
|
|
|
*/
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1300)
|
|
|
|
|
check_for_user_defined_postfix_ops(&old_cluster);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* PG 14 changed polymorphic functions from anyarray to
|
|
|
|
|
* anycompatiblearray.
|
|
|
|
|
*/
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1300)
|
|
|
|
|
check_for_incompatible_polymorphics(&old_cluster);
|
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
/*
|
|
|
|
|
* Pre-PG 12 allowed tables to be declared WITH OIDS, which is not
|
|
|
|
|
* supported anymore. Verify there are none, iff applicable.
|
|
|
|
|
*/
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1100)
|
|
|
|
|
check_for_tables_with_oids(&old_cluster);
|
|
|
|
|
|
Check for tables with sql_identifier during pg_upgrade
Commit 7c15cef86d changed sql_identifier data type to be based on name
instead of varchar. Unfortunately, this breaks on-disk format for this
data type. Luckily, that should be a very rare problem, as this data
type is used only in information_schema views, so this only affects user
objects (tables, materialized views and indexes). One way to end in
such situation is to do CTAS with a query on those system views.
There are two options to deal with this - we can either abort pg_upgrade
if there are user objects with sql_identifier columns in pg_upgrade, or
we could replace the sql_identifier type with varchar. Considering how
rare the issue is expected to be, and the complexity of replacing the
data type (e.g. in matviews), we've decided to go with the simple check.
The query is somewhat complex - the sql_identifier data type may be used
indirectly - through a domain, a composite type or both, possibly in
multiple levels. Detecting this requires a recursive CTE.
Backpatch to 12, where the sql_identifier definition changed.
Reported-by: Hans Buschmann
Author: Tomas Vondra
Reviewed-by: Tom Lane
Backpatch-to: 12
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
6 years ago
|
|
|
/*
|
|
|
|
|
* PG 12 changed the 'sql_identifier' type storage to be based on name,
|
|
|
|
|
* not varchar, which breaks on-disk format for existing data. So we need
|
|
|
|
|
* to prevent upgrade when used in user objects (tables, indexes, ...).
|
|
|
|
|
*/
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1100)
|
|
|
|
|
old_11_check_for_sql_identifier_data_type_usage(&old_cluster);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Pre-PG 10 allowed tables with 'unknown' type columns and non WAL logged
|
|
|
|
|
* hash indexes
|
|
|
|
|
*/
|
Change unknown-type literals to type text in SELECT and RETURNING lists.
Previously, we left such literals alone if the query or subquery had
no properties forcing a type decision to be made (such as an ORDER BY or
DISTINCT clause using that output column). This meant that "unknown" could
be an exposed output column type, which has never been a great idea because
it could result in strange failures later on. For example, an outer query
that tried to do any operations on an unknown-type subquery output would
generally fail with some weird error like "failed to find conversion
function from unknown to text" or "could not determine which collation to
use for string comparison". Also, if the case occurred in a CREATE VIEW's
query then the view would have an unknown-type column, causing similar
failures in queries trying to use the view.
To fix, at the tail end of parse analysis of a query, forcibly convert any
remaining "unknown" literals in its SELECT or RETURNING list to type text.
However, provide a switch to suppress that, and use it in the cases of
SELECT inside a set operation or INSERT command. In those cases we already
had type resolution rules that make use of context information from outside
the subquery proper, and we don't want to change that behavior.
Also, change creation of an unknown-type column in a relation from a
warning to a hard error. The error should be unreachable now in CREATE
VIEW or CREATE MATVIEW, but it's still possible to explicitly say "unknown"
in CREATE TABLE or CREATE (composite) TYPE. We want to forbid that because
it's nothing but a foot-gun.
This change creates a pg_upgrade failure case: a matview that contains an
unknown-type column can't be pg_upgraded, because reparsing the matview's
defining query will now decide that the column is of type text, which
doesn't match the cstring-like storage that the old materialized column
would actually have. Add a checking pass to detect that. While at it,
we can detect tables or composite types that would fail, essentially
for free. Those would fail safely anyway later on, but we might as
well fail earlier.
This patch is by me, but it owes something to previous investigations
by Rahila Syed. Also thanks to Ashutosh Bapat and Michael Paquier for
review.
Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
9 years ago
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 906)
|
|
|
|
|
{
|
Change unknown-type literals to type text in SELECT and RETURNING lists.
Previously, we left such literals alone if the query or subquery had
no properties forcing a type decision to be made (such as an ORDER BY or
DISTINCT clause using that output column). This meant that "unknown" could
be an exposed output column type, which has never been a great idea because
it could result in strange failures later on. For example, an outer query
that tried to do any operations on an unknown-type subquery output would
generally fail with some weird error like "failed to find conversion
function from unknown to text" or "could not determine which collation to
use for string comparison". Also, if the case occurred in a CREATE VIEW's
query then the view would have an unknown-type column, causing similar
failures in queries trying to use the view.
To fix, at the tail end of parse analysis of a query, forcibly convert any
remaining "unknown" literals in its SELECT or RETURNING list to type text.
However, provide a switch to suppress that, and use it in the cases of
SELECT inside a set operation or INSERT command. In those cases we already
had type resolution rules that make use of context information from outside
the subquery proper, and we don't want to change that behavior.
Also, change creation of an unknown-type column in a relation from a
warning to a hard error. The error should be unreachable now in CREATE
VIEW or CREATE MATVIEW, but it's still possible to explicitly say "unknown"
in CREATE TABLE or CREATE (composite) TYPE. We want to forbid that because
it's nothing but a foot-gun.
This change creates a pg_upgrade failure case: a matview that contains an
unknown-type column can't be pg_upgraded, because reparsing the matview's
defining query will now decide that the column is of type text, which
doesn't match the cstring-like storage that the old materialized column
would actually have. Add a checking pass to detect that. While at it,
we can detect tables or composite types that would fail, essentially
for free. Those would fail safely anyway later on, but we might as
well fail earlier.
This patch is by me, but it owes something to previous investigations
by Rahila Syed. Also thanks to Ashutosh Bapat and Michael Paquier for
review.
Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
9 years ago
|
|
|
old_9_6_check_for_unknown_data_type_usage(&old_cluster);
|
|
|
|
|
if (user_opts.check)
|
|
|
|
|
old_9_6_invalidate_hash_indexes(&old_cluster, true);
|
|
|
|
|
}
|
Change unknown-type literals to type text in SELECT and RETURNING lists.
Previously, we left such literals alone if the query or subquery had
no properties forcing a type decision to be made (such as an ORDER BY or
DISTINCT clause using that output column). This meant that "unknown" could
be an exposed output column type, which has never been a great idea because
it could result in strange failures later on. For example, an outer query
that tried to do any operations on an unknown-type subquery output would
generally fail with some weird error like "failed to find conversion
function from unknown to text" or "could not determine which collation to
use for string comparison". Also, if the case occurred in a CREATE VIEW's
query then the view would have an unknown-type column, causing similar
failures in queries trying to use the view.
To fix, at the tail end of parse analysis of a query, forcibly convert any
remaining "unknown" literals in its SELECT or RETURNING list to type text.
However, provide a switch to suppress that, and use it in the cases of
SELECT inside a set operation or INSERT command. In those cases we already
had type resolution rules that make use of context information from outside
the subquery proper, and we don't want to change that behavior.
Also, change creation of an unknown-type column in a relation from a
warning to a hard error. The error should be unreachable now in CREATE
VIEW or CREATE MATVIEW, but it's still possible to explicitly say "unknown"
in CREATE TABLE or CREATE (composite) TYPE. We want to forbid that because
it's nothing but a foot-gun.
This change creates a pg_upgrade failure case: a matview that contains an
unknown-type column can't be pg_upgraded, because reparsing the matview's
defining query will now decide that the column is of type text, which
doesn't match the cstring-like storage that the old materialized column
would actually have. Add a checking pass to detect that. While at it,
we can detect tables or composite types that would fail, essentially
for free. Those would fail safely anyway later on, but we might as
well fail earlier.
This patch is by me, but it owes something to previous investigations
by Rahila Syed. Also thanks to Ashutosh Bapat and Michael Paquier for
review.
Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
9 years ago
|
|
|
|
|
|
|
|
/* 9.5 and below should not have roles starting with pg_ */
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 905)
|
|
|
|
|
check_for_pg_role_prefix(&old_cluster);
|
|
|
|
|
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) == 904 &&
|
|
|
|
|
old_cluster.controldata.cat_ver < JSONB_FORMAT_CHANGE_CAT_VER)
|
|
|
|
|
check_for_jsonb_9_4_usage(&old_cluster);
|
|
|
|
|
|
|
|
|
|
/* Pre-PG 9.4 had a different 'line' data type internal format */
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 903)
|
|
|
|
|
old_9_3_check_for_line_data_type_usage(&old_cluster);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* While not a check option, we do this now because this is the only time
|
|
|
|
|
* the old server is running.
|
|
|
|
|
*/
|
|
|
|
|
if (!user_opts.check)
|
|
|
|
|
generate_old_dump();
|
|
|
|
|
|
|
|
|
|
if (!live_check)
|
|
|
|
|
stop_postmaster(false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
check_new_cluster(void)
|
|
|
|
|
{
|
|
|
|
|
get_db_and_rel_infos(&new_cluster);
|
|
|
|
|
|
|
|
|
|
check_new_cluster_is_empty();
|
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
|
|
|
check_databases_are_compatible();
|
|
|
|
|
|
|
|
|
|
check_loadable_libraries();
|
|
|
|
|
|
|
|
|
|
switch (user_opts.transfer_mode)
|
|
|
|
|
{
|
|
|
|
|
case TRANSFER_MODE_CLONE:
|
|
|
|
|
check_file_clone();
|
|
|
|
|
break;
|
|
|
|
|
case TRANSFER_MODE_COPY:
|
|
|
|
|
break;
|
|
|
|
|
case TRANSFER_MODE_LINK:
|
|
|
|
|
check_hard_link();
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
check_is_install_user(&new_cluster);
|
|
|
|
|
|
|
|
|
|
check_for_prepared_transactions(&new_cluster);
|
|
|
|
|
|
|
|
|
|
check_for_new_tablespace_dir(&new_cluster);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
report_clusters_compatible(void)
|
|
|
|
|
{
|
|
|
|
|
if (user_opts.check)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "\n*Clusters are compatible*\n");
|
|
|
|
|
/* stops new cluster */
|
|
|
|
|
stop_postmaster(false);
|
Restructure pg_upgrade output directories for better idempotence
38bfae3 has moved the contents written to files by pg_upgrade under a
new directory called pg_upgrade_output.d/ located in the new cluster's
data folder, and it used a simple structure made of two subdirectories
leading to a fixed structure: log/ and dump/. This design has made
weaker pg_upgrade on repeated calls, as we could get failures when
creating one or more of those directories, while potentially losing the
logs of a previous run (logs are retained automatically on failure, and
cleaned up on success unless --retain is specified). So a user would
need to clean up pg_upgrade_output.d/ as an extra step for any repeated
calls of pg_upgrade. The most common scenario here is --check followed
by the actual upgrade, but one could see a failure when specifying an
incorrect input argument value. Removing entirely the logs would have
the disadvantage of removing all the past information, even if --retain
was specified at some past step.
This result is annoying for a lot of users and automated upgrade flows.
So, rather than requiring a manual removal of pg_upgrade_output.d/, this
redesigns the set of output directories in a more dynamic way, based on
a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/
is still the base path, but a second directory level is added, mostly
named after an ISO-8601-formatted timestamp (in short human-readable,
with milliseconds appended to the name to avoid any conflicts). The
logs and dumps are saved within the same subdirectories as previously,
as of log/ and dump/, but these are located inside the subdirectory
named after the timestamp.
The logs of a given run are removed only after a successful run if
--retain is not used, and pg_upgrade_output.d/ is kept if there are any
logs from a previous run. Note that previously, pg_upgrade would have
kept the logs even after a successful --check but that was inconsistent
compared to the case without --check when using --retain. The code in
charge of the removal of the output directories is now refactored into a
single routine.
Two TAP tests are added with some --check commands (one failure case and
one success case), to look after the issue fixed here. Note that the
tests had to be tweaked a bit to fit with the new directory structure so
as it can find any logs generated on failure. This is still going to
require a change in the buildfarm client for the case where pg_upgrade
is tested without the TAP test, though, but I'll tackle that with a
separate patch where needed.
Reported-by: Tushar Ahuja
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson, Justin Pryzby
Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
4 years ago
|
|
|
|
|
|
|
|
cleanup_output_dirs();
|
|
|
|
|
exit(0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pg_log(PG_REPORT, "\n"
|
|
|
|
|
"If pg_upgrade fails after this point, you must re-initdb the\n"
|
|
|
|
|
"new cluster before continuing.\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
issue_warnings_and_set_wal_level(void)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* We unconditionally start/stop the new server because pg_resetwal -o set
|
|
|
|
|
* wal_level to 'minimum'. If the user is upgrading standby servers using
|
|
|
|
|
* the rsync instructions, they will need pg_upgrade to write its final
|
|
|
|
|
* WAL record showing wal_level as 'replica'.
|
|
|
|
|
*/
|
|
|
|
|
start_postmaster(&new_cluster, true);
|
|
|
|
|
|
|
|
|
|
/* Reindex hash indexes for old < 10.0 */
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 906)
|
|
|
|
|
old_9_6_invalidate_hash_indexes(&new_cluster, false);
|
|
|
|
|
|
|
|
|
|
report_extension_updates(&new_cluster);
|
|
|
|
|
|
|
|
|
|
stop_postmaster(false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
output_completion_banner(char *deletion_script_file_name)
|
|
|
|
|
{
|
|
|
|
|
PQExpBufferData user_specification;
|
|
|
|
|
|
|
|
|
|
initPQExpBuffer(&user_specification);
|
|
|
|
|
if (os_info.user_specified)
|
|
|
|
|
{
|
|
|
|
|
appendPQExpBufferStr(&user_specification, "-U ");
|
|
|
|
|
appendShellString(&user_specification, os_info.user);
|
|
|
|
|
appendPQExpBufferChar(&user_specification, ' ');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pg_log(PG_REPORT,
|
|
|
|
|
"Optimizer statistics are not transferred by pg_upgrade.\n"
|
|
|
|
|
"Once you start the new server, consider running:\n"
|
|
|
|
|
" %s/vacuumdb %s--all --analyze-in-stages\n\n", new_cluster.bindir, user_specification.data);
|
|
|
|
|
|
|
|
|
|
if (deletion_script_file_name)
|
|
|
|
|
pg_log(PG_REPORT,
|
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
|
|
|
"Running this script will delete the old cluster's data files:\n"
|
|
|
|
|
" %s\n",
|
|
|
|
|
deletion_script_file_name);
|
|
|
|
|
else
|
|
|
|
|
pg_log(PG_REPORT,
|
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
|
|
|
"Could not create a script to delete the old cluster's data files\n"
|
|
|
|
|
"because user-defined tablespaces or the new cluster's data directory\n"
|
|
|
|
|
"exist in the old cluster directory. The old cluster's contents must\n"
|
|
|
|
|
"be deleted manually.\n");
|
|
|
|
|
|
|
|
|
|
termPQExpBuffer(&user_specification);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
check_cluster_versions(void)
|
|
|
|
|
{
|
|
|
|
|
prep_status("Checking cluster versions");
|
|
|
|
|
|
|
|
|
|
/* cluster versions should already have been obtained */
|
|
|
|
|
Assert(old_cluster.major_version != 0);
|
|
|
|
|
Assert(new_cluster.major_version != 0);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We allow upgrades from/to the same major version for alpha/beta
|
|
|
|
|
* upgrades
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) < 902)
|
|
|
|
|
pg_fatal("This utility can only upgrade from PostgreSQL version %s and later.\n",
|
|
|
|
|
"9.2");
|
|
|
|
|
|
|
|
|
|
/* Only current PG version is supported as a target */
|
|
|
|
|
if (GET_MAJOR_VERSION(new_cluster.major_version) != GET_MAJOR_VERSION(PG_VERSION_NUM))
|
|
|
|
|
pg_fatal("This utility can only upgrade to PostgreSQL version %s.\n",
|
|
|
|
|
PG_MAJORVERSION);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We can't allow downgrading because we use the target pg_dump, and
|
|
|
|
|
* pg_dump cannot operate on newer database versions, only current and
|
|
|
|
|
* older versions.
|
|
|
|
|
*/
|
|
|
|
|
if (old_cluster.major_version > new_cluster.major_version)
|
|
|
|
|
pg_fatal("This utility cannot be used to downgrade to older major PostgreSQL versions.\n");
|
|
|
|
|
|
|
|
|
|
/* Ensure binaries match the designated data directories */
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) !=
|
|
|
|
|
GET_MAJOR_VERSION(old_cluster.bin_version))
|
|
|
|
|
pg_fatal("Old cluster data and binary directories are from different major versions.\n");
|
|
|
|
|
if (GET_MAJOR_VERSION(new_cluster.major_version) !=
|
|
|
|
|
GET_MAJOR_VERSION(new_cluster.bin_version))
|
|
|
|
|
pg_fatal("New cluster data and binary directories are from different major versions.\n");
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
check_cluster_compatibility(bool live_check)
|
|
|
|
|
{
|
|
|
|
|
/* get/check pg_control data of servers */
|
|
|
|
|
get_control_data(&old_cluster, live_check);
|
|
|
|
|
get_control_data(&new_cluster, false);
|
|
|
|
|
check_control_data(&old_cluster.controldata, &new_cluster.controldata);
|
|
|
|
|
|
|
|
|
|
if (live_check && old_cluster.port == new_cluster.port)
|
|
|
|
|
pg_fatal("When checking a live server, "
|
|
|
|
|
"the old and new port numbers must be different.\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_locale_and_encoding()
|
|
|
|
|
*
|
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
|
|
|
* Check that locale and encoding of a database in the old and new clusters
|
|
|
|
|
* are compatible.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
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
|
|
|
check_locale_and_encoding(DbInfo *olddb, DbInfo *newdb)
|
|
|
|
|
{
|
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
|
|
|
if (olddb->db_encoding != newdb->db_encoding)
|
|
|
|
|
pg_fatal("encodings for database \"%s\" do not match: old \"%s\", new \"%s\"\n",
|
|
|
|
|
olddb->db_name,
|
|
|
|
|
pg_encoding_to_char(olddb->db_encoding),
|
|
|
|
|
pg_encoding_to_char(newdb->db_encoding));
|
|
|
|
|
if (!equivalent_locale(LC_COLLATE, olddb->db_collate, newdb->db_collate))
|
|
|
|
|
pg_fatal("lc_collate values for database \"%s\" do not match: old \"%s\", new \"%s\"\n",
|
|
|
|
|
olddb->db_name, olddb->db_collate, newdb->db_collate);
|
|
|
|
|
if (!equivalent_locale(LC_CTYPE, olddb->db_ctype, newdb->db_ctype))
|
|
|
|
|
pg_fatal("lc_ctype values for database \"%s\" do not match: old \"%s\", new \"%s\"\n",
|
|
|
|
|
olddb->db_name, olddb->db_ctype, newdb->db_ctype);
|
|
|
|
|
if (olddb->db_collprovider != newdb->db_collprovider)
|
|
|
|
|
pg_fatal("locale providers for database \"%s\" do not match: old \"%s\", new \"%s\"\n",
|
|
|
|
|
olddb->db_name,
|
|
|
|
|
collprovider_name(olddb->db_collprovider),
|
|
|
|
|
collprovider_name(newdb->db_collprovider));
|
|
|
|
|
if ((olddb->db_iculocale == NULL && newdb->db_iculocale != NULL) ||
|
|
|
|
|
(olddb->db_iculocale != NULL && newdb->db_iculocale == NULL) ||
|
|
|
|
|
(olddb->db_iculocale != NULL && newdb->db_iculocale != NULL && strcmp(olddb->db_iculocale, newdb->db_iculocale) != 0))
|
|
|
|
|
pg_fatal("ICU locale values for database \"%s\" do not match: old \"%s\", new \"%s\"\n",
|
|
|
|
|
olddb->db_name,
|
|
|
|
|
olddb->db_iculocale ? olddb->db_iculocale : "(null)",
|
|
|
|
|
newdb->db_iculocale ? newdb->db_iculocale : "(null)");
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* equivalent_locale()
|
|
|
|
|
*
|
|
|
|
|
* Best effort locale-name comparison. Return false if we are not 100% sure
|
|
|
|
|
* the locales are equivalent.
|
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
|
|
|
*
|
|
|
|
|
* Note: The encoding parts of the names are ignored. This function is
|
|
|
|
|
* currently used to compare locale names stored in pg_database, and
|
|
|
|
|
* pg_database contains a separate encoding field. That's compared directly
|
|
|
|
|
* in check_locale_and_encoding().
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
*/
|
|
|
|
|
static bool
|
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
|
|
|
equivalent_locale(int category, const char *loca, const char *locb)
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
{
|
|
|
|
|
const char *chara;
|
|
|
|
|
const char *charb;
|
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
|
|
|
char *canona;
|
|
|
|
|
char *canonb;
|
|
|
|
|
int lena;
|
|
|
|
|
int lenb;
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the names are equal, the locales are equivalent. Checking this first
|
|
|
|
|
* avoids calling setlocale() in the common case that the names are equal.
|
|
|
|
|
* That's a good thing, if setlocale() is buggy, for example.
|
|
|
|
|
*/
|
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
|
|
|
if (pg_strcasecmp(loca, locb) == 0)
|
|
|
|
|
return true;
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Not identical. Canonicalize both names, remove the encoding parts, and
|
|
|
|
|
* try again.
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
*/
|
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
|
|
|
canona = get_canonical_locale_name(category, loca);
|
|
|
|
|
chara = strrchr(canona, '.');
|
|
|
|
|
lena = chara ? (chara - canona) : strlen(canona);
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
|
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
|
|
|
canonb = get_canonical_locale_name(category, locb);
|
|
|
|
|
charb = strrchr(canonb, '.');
|
|
|
|
|
lenb = charb ? (charb - canonb) : strlen(canonb);
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
|
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
|
|
|
if (lena == lenb && pg_strncasecmp(canona, canonb, lena) == 0)
|
|
|
|
|
{
|
|
|
|
|
pg_free(canona);
|
|
|
|
|
pg_free(canonb);
|
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
|
|
|
return true;
|
|
|
|
|
}
|
Be forgiving of variant spellings of locale names in pg_upgrade.
Even though the server tries to canonicalize stored locale names, the
platform often doesn't cooperate, so it's entirely possible that one DB
thinks its locale is, say, "en_US.UTF-8" while the other has "en_US.utf8".
Rather than failing, we should try to allow this where it's clearly OK.
There is already pretty robust encoding lookup in encnames.c, so make
use of that to compare the encoding parts of the names. The locale
identifier parts are just compared case-insensitively, which we were
already doing. The major problem known to exist in the field is variant
encoding-name spellings, so hopefully this will be Good Enough. If not,
we can try being even laxer.
Pavel Raiskup, reviewed by Rushabh Lathia
12 years ago
|
|
|
|
|
|
|
|
pg_free(canona);
|
|
|
|
|
pg_free(canonb);
|
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
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
check_new_cluster_is_empty(void)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < new_cluster.dbarr.ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
int relnum;
|
|
|
|
|
RelInfoArr *rel_arr = &new_cluster.dbarr.dbs[dbnum].rel_arr;
|
|
|
|
|
|
|
|
|
|
for (relnum = 0; relnum < rel_arr->nrels;
|
|
|
|
|
relnum++)
|
|
|
|
|
{
|
|
|
|
|
/* pg_largeobject and its index should be skipped */
|
|
|
|
|
if (strcmp(rel_arr->rels[relnum].nspname, "pg_catalog") != 0)
|
|
|
|
|
pg_fatal("New cluster database \"%s\" is not empty: found relation \"%s.%s\"\n",
|
|
|
|
|
new_cluster.dbarr.dbs[dbnum].db_name,
|
|
|
|
|
rel_arr->rels[relnum].nspname,
|
|
|
|
|
rel_arr->rels[relnum].relname);
|
|
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check that every database that already exists in the new cluster is
|
|
|
|
|
* compatible with the corresponding database in the old one.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_databases_are_compatible(void)
|
|
|
|
|
{
|
|
|
|
|
int newdbnum;
|
|
|
|
|
int olddbnum;
|
|
|
|
|
DbInfo *newdbinfo;
|
|
|
|
|
DbInfo *olddbinfo;
|
|
|
|
|
|
|
|
|
|
for (newdbnum = 0; newdbnum < new_cluster.dbarr.ndbs; newdbnum++)
|
|
|
|
|
{
|
|
|
|
|
newdbinfo = &new_cluster.dbarr.dbs[newdbnum];
|
|
|
|
|
|
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
|
|
|
/* Find the corresponding database in the old cluster */
|
|
|
|
|
for (olddbnum = 0; olddbnum < old_cluster.dbarr.ndbs; olddbnum++)
|
|
|
|
|
{
|
|
|
|
|
olddbinfo = &old_cluster.dbarr.dbs[olddbnum];
|
|
|
|
|
if (strcmp(newdbinfo->db_name, olddbinfo->db_name) == 0)
|
|
|
|
|
{
|
|
|
|
|
check_locale_and_encoding(olddbinfo, newdbinfo);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A previous run of pg_upgrade might have failed and the new cluster
|
|
|
|
|
* directory recreated, but they might have forgotten to remove
|
|
|
|
|
* the new cluster's tablespace directories. Therefore, check that
|
|
|
|
|
* new cluster tablespace directories do not already exist. If
|
|
|
|
|
* they do, it would cause an error while restoring global objects.
|
|
|
|
|
* This allows the failure to be detected at check time, rather than
|
|
|
|
|
* during schema restore.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_new_tablespace_dir(ClusterInfo *new_cluster)
|
|
|
|
|
{
|
|
|
|
|
int tblnum;
|
|
|
|
|
char new_tablespace_dir[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for new cluster tablespace directories");
|
|
|
|
|
|
|
|
|
|
for (tblnum = 0; tblnum < os_info.num_old_tablespaces; tblnum++)
|
|
|
|
|
{
|
|
|
|
|
struct stat statbuf;
|
|
|
|
|
|
|
|
|
|
snprintf(new_tablespace_dir, MAXPGPATH, "%s%s",
|
|
|
|
|
os_info.old_tablespaces[tblnum],
|
|
|
|
|
new_cluster->tablespace_suffix);
|
|
|
|
|
|
|
|
|
|
if (stat(new_tablespace_dir, &statbuf) == 0 || errno != ENOENT)
|
|
|
|
|
pg_fatal("new cluster tablespace directory already exists: \"%s\"\n",
|
|
|
|
|
new_tablespace_dir);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* create_script_for_old_cluster_deletion()
|
|
|
|
|
*
|
|
|
|
|
* This is particularly useful for tablespace deletion.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
create_script_for_old_cluster_deletion(char **deletion_script_file_name)
|
|
|
|
|
{
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
int tblnum;
|
|
|
|
|
char old_cluster_pgdata[MAXPGPATH],
|
|
|
|
|
new_cluster_pgdata[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
*deletion_script_file_name = psprintf("%sdelete_old_cluster.%s",
|
|
|
|
|
SCRIPT_PREFIX, SCRIPT_EXT);
|
|
|
|
|
|
|
|
|
|
strlcpy(old_cluster_pgdata, old_cluster.pgdata, MAXPGPATH);
|
|
|
|
|
canonicalize_path(old_cluster_pgdata);
|
|
|
|
|
|
|
|
|
|
strlcpy(new_cluster_pgdata, new_cluster.pgdata, MAXPGPATH);
|
|
|
|
|
canonicalize_path(new_cluster_pgdata);
|
|
|
|
|
|
|
|
|
|
/* Some people put the new data directory inside the old one. */
|
|
|
|
|
if (path_is_prefix_of_path(old_cluster_pgdata, new_cluster_pgdata))
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_WARNING,
|
|
|
|
|
"\nWARNING: new data directory should not be inside the old data directory, e.g. %s\n", old_cluster_pgdata);
|
|
|
|
|
|
|
|
|
|
/* Unlink file in case it is left over from a previous run. */
|
|
|
|
|
unlink(*deletion_script_file_name);
|
|
|
|
|
pg_free(*deletion_script_file_name);
|
|
|
|
|
*deletion_script_file_name = NULL;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Some users (oddly) create tablespaces inside the cluster data
|
|
|
|
|
* directory. We can't create a proper old cluster delete script in that
|
|
|
|
|
* case.
|
|
|
|
|
*/
|
|
|
|
|
for (tblnum = 0; tblnum < os_info.num_old_tablespaces; tblnum++)
|
|
|
|
|
{
|
|
|
|
|
char old_tablespace_dir[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
strlcpy(old_tablespace_dir, os_info.old_tablespaces[tblnum], MAXPGPATH);
|
|
|
|
|
canonicalize_path(old_tablespace_dir);
|
|
|
|
|
if (path_is_prefix_of_path(old_cluster_pgdata, old_tablespace_dir))
|
|
|
|
|
{
|
|
|
|
|
/* reproduce warning from CREATE TABLESPACE that is in the log */
|
|
|
|
|
pg_log(PG_WARNING,
|
|
|
|
|
"\nWARNING: user-defined tablespace locations should not be inside the data directory, e.g. %s\n", old_tablespace_dir);
|
|
|
|
|
|
|
|
|
|
/* Unlink file in case it is left over from a previous run. */
|
|
|
|
|
unlink(*deletion_script_file_name);
|
|
|
|
|
pg_free(*deletion_script_file_name);
|
|
|
|
|
*deletion_script_file_name = NULL;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
prep_status("Creating script to delete old cluster");
|
|
|
|
|
|
|
|
|
|
if ((script = fopen_priv(*deletion_script_file_name, "w")) == NULL)
|
Improve error reporting in pg_upgrade's file copying/linking/rewriting.
The previous design for this had copyFile(), linkFile(), and
rewriteVisibilityMap() returning strerror strings, with the caller
producing one-size-fits-all error messages based on that. This made it
impossible to produce messages that described the failures with any degree
of precision, especially not short-read problems since those don't set
errno at all.
Since pg_upgrade has no intention of continuing after any error in this
area, let's fix this by just letting these functions call pg_fatal() for
themselves, making it easy for each point of failure to have a suitable
error message. Taking this approach also allows dropping cleanup code
that was unnecessary and was often rather sloppy about preserving errno.
To not lose relevant info that was reported before, pass in the schema name
and table name of the current table so that they can be included in the
error reports.
An additional problem was the use of getErrorText(), which was flat out
wrong for all but a couple of call sites, because it unconditionally did
"_dosmaperr(GetLastError())" on Windows. That's only appropriate when
reporting an error from a Windows-native API, which only a couple of
the callers were actually doing. Thus, even the reported strerror string
would be unrelated to the actual failure in many cases on Windows.
To fix, get rid of getErrorText() altogether, and just have call sites
do strerror(errno) instead, since that's the way all the rest of our
frontend programs do it. Add back the _dosmaperr() calls in the two
places where that's actually appropriate.
In passing, make assorted messages hew more closely to project style
guidelines, notably by removing initial capitals in not-complete-sentence
primary error messages. (I didn't make any effort to clean up places
I didn't have another reason to touch, though.)
Per discussion of a report from Thomas Kellerer. Back-patch to 9.6,
but no further; given the relative infrequency of reports of problems
here, it's not clear it's worth adapting the patch to older branches.
Patch by me, but with credit to Alvaro Herrera for spotting the issue
with getErrorText's misuse of _dosmaperr().
Discussion: <nsjrbh$8li$1@blaine.gmane.org>
9 years ago
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
*deletion_script_file_name, strerror(errno));
|
|
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
|
/* add shebang header */
|
|
|
|
|
fprintf(script, "#!/bin/sh\n\n");
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* delete old cluster's default tablespace */
|
|
|
|
|
fprintf(script, RMDIR_CMD " %c%s%c\n", PATH_QUOTE,
|
|
|
|
|
fix_path_separator(old_cluster.pgdata), PATH_QUOTE);
|
|
|
|
|
|
|
|
|
|
/* delete old cluster's alternate tablespaces */
|
|
|
|
|
for (tblnum = 0; tblnum < os_info.num_old_tablespaces; tblnum++)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Do the old cluster's per-database directories share a directory
|
|
|
|
|
* with a new version-specific tablespace?
|
|
|
|
|
*/
|
|
|
|
|
if (strlen(old_cluster.tablespace_suffix) == 0)
|
|
|
|
|
{
|
|
|
|
|
/* delete per-database directories */
|
|
|
|
|
int dbnum;
|
|
|
|
|
|
|
|
|
|
fprintf(script, "\n");
|
|
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++)
|
|
|
|
|
fprintf(script, RMDIR_CMD " %c%s%c%u%c\n", PATH_QUOTE,
|
|
|
|
|
fix_path_separator(os_info.old_tablespaces[tblnum]),
|
|
|
|
|
PATH_SEPARATOR, old_cluster.dbarr.dbs[dbnum].db_oid,
|
|
|
|
|
PATH_QUOTE);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
char *suffix_path = pg_strdup(old_cluster.tablespace_suffix);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Simply delete the tablespace directory, which might be ".old"
|
|
|
|
|
* or a version-specific subdirectory.
|
|
|
|
|
*/
|
|
|
|
|
fprintf(script, RMDIR_CMD " %c%s%s%c\n", PATH_QUOTE,
|
|
|
|
|
fix_path_separator(os_info.old_tablespaces[tblnum]),
|
|
|
|
|
fix_path_separator(suffix_path), PATH_QUOTE);
|
|
|
|
|
pfree(suffix_path);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
|
if (chmod(*deletion_script_file_name, S_IRWXU) != 0)
|
Improve error reporting in pg_upgrade's file copying/linking/rewriting.
The previous design for this had copyFile(), linkFile(), and
rewriteVisibilityMap() returning strerror strings, with the caller
producing one-size-fits-all error messages based on that. This made it
impossible to produce messages that described the failures with any degree
of precision, especially not short-read problems since those don't set
errno at all.
Since pg_upgrade has no intention of continuing after any error in this
area, let's fix this by just letting these functions call pg_fatal() for
themselves, making it easy for each point of failure to have a suitable
error message. Taking this approach also allows dropping cleanup code
that was unnecessary and was often rather sloppy about preserving errno.
To not lose relevant info that was reported before, pass in the schema name
and table name of the current table so that they can be included in the
error reports.
An additional problem was the use of getErrorText(), which was flat out
wrong for all but a couple of call sites, because it unconditionally did
"_dosmaperr(GetLastError())" on Windows. That's only appropriate when
reporting an error from a Windows-native API, which only a couple of
the callers were actually doing. Thus, even the reported strerror string
would be unrelated to the actual failure in many cases on Windows.
To fix, get rid of getErrorText() altogether, and just have call sites
do strerror(errno) instead, since that's the way all the rest of our
frontend programs do it. Add back the _dosmaperr() calls in the two
places where that's actually appropriate.
In passing, make assorted messages hew more closely to project style
guidelines, notably by removing initial capitals in not-complete-sentence
primary error messages. (I didn't make any effort to clean up places
I didn't have another reason to touch, though.)
Per discussion of a report from Thomas Kellerer. Back-patch to 9.6,
but no further; given the relative infrequency of reports of problems
here, it's not clear it's worth adapting the patch to older branches.
Patch by me, but with credit to Alvaro Herrera for spotting the issue
with getErrorText's misuse of _dosmaperr().
Discussion: <nsjrbh$8li$1@blaine.gmane.org>
9 years ago
|
|
|
pg_fatal("could not add execute permission to file \"%s\": %s\n",
|
|
|
|
|
*deletion_script_file_name, strerror(errno));
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_is_install_user()
|
|
|
|
|
*
|
|
|
|
|
* Check we are the install user, and that the new cluster
|
|
|
|
|
* has no other users.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_is_install_user(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
PGconn *conn = connectToServer(cluster, "template1");
|
|
|
|
|
|
|
|
|
|
prep_status("Checking database user is the install user");
|
|
|
|
|
|
|
|
|
|
/* Can't use pg_authid because only superusers can view it. */
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT rolsuper, oid "
|
|
|
|
|
"FROM pg_catalog.pg_roles "
|
|
|
|
|
"WHERE rolname = current_user "
|
|
|
|
|
"AND rolname !~ '^pg_'");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We only allow the install user in the new cluster (see comment below)
|
|
|
|
|
* and we preserve pg_authid.oid, so this must be the install user in the
|
|
|
|
|
* old cluster too.
|
|
|
|
|
*/
|
|
|
|
|
if (PQntuples(res) != 1 ||
|
|
|
|
|
atooid(PQgetvalue(res, 0, 1)) != BOOTSTRAP_SUPERUSERID)
|
|
|
|
|
pg_fatal("database user \"%s\" is not the install user\n",
|
|
|
|
|
os_info.user);
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT COUNT(*) "
|
|
|
|
|
"FROM pg_catalog.pg_roles "
|
|
|
|
|
"WHERE rolname !~ '^pg_'");
|
|
|
|
|
|
|
|
|
|
if (PQntuples(res) != 1)
|
|
|
|
|
pg_fatal("could not determine the number of users\n");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We only allow the install user in the new cluster because other defined
|
|
|
|
|
* users might match users defined in the old cluster and generate an
|
|
|
|
|
* error during pg_dump restore.
|
|
|
|
|
*/
|
|
|
|
|
if (cluster == &new_cluster && atooid(PQgetvalue(res, 0, 0)) != 1)
|
|
|
|
|
pg_fatal("Only the install user can be defined in the new cluster.\n");
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_proper_datallowconn
|
|
|
|
|
*
|
|
|
|
|
* Ensure that all non-template0 databases allow connections since they
|
|
|
|
|
* otherwise won't be restored; and that template0 explicitly doesn't allow
|
|
|
|
|
* connections since it would make pg_dumpall --globals restore fail.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_proper_datallowconn(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
PGconn *conn_template1;
|
|
|
|
|
PGresult *dbres;
|
|
|
|
|
int ntups;
|
|
|
|
|
int i_datname;
|
|
|
|
|
int i_datallowconn;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
|
|
prep_status("Checking database connection settings");
|
|
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path), "%s/%s",
|
|
|
|
|
log_opts.basedir,
|
|
|
|
|
"databases_with_datallowconn_false.txt");
|
|
|
|
|
|
|
|
|
|
conn_template1 = connectToServer(cluster, "template1");
|
|
|
|
|
|
|
|
|
|
/* get database names */
|
|
|
|
|
dbres = executeQueryOrDie(conn_template1,
|
|
|
|
|
"SELECT datname, datallowconn "
|
|
|
|
|
"FROM pg_catalog.pg_database");
|
|
|
|
|
|
|
|
|
|
i_datname = PQfnumber(dbres, "datname");
|
|
|
|
|
i_datallowconn = PQfnumber(dbres, "datallowconn");
|
|
|
|
|
|
|
|
|
|
ntups = PQntuples(dbres);
|
|
|
|
|
for (dbnum = 0; dbnum < ntups; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
char *datname = PQgetvalue(dbres, dbnum, i_datname);
|
|
|
|
|
char *datallowconn = PQgetvalue(dbres, dbnum, i_datallowconn);
|
|
|
|
|
|
|
|
|
|
if (strcmp(datname, "template0") == 0)
|
|
|
|
|
{
|
|
|
|
|
/* avoid restore failure when pg_dumpall tries to create template0 */
|
|
|
|
|
if (strcmp(datallowconn, "t") == 0)
|
|
|
|
|
pg_fatal("template0 must not allow connections, "
|
|
|
|
|
"i.e. its pg_database.datallowconn must be false\n");
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* avoid datallowconn == false databases from being skipped on
|
|
|
|
|
* restore
|
|
|
|
|
*/
|
|
|
|
|
if (strcmp(datallowconn, "f") == 0)
|
|
|
|
|
{
|
|
|
|
|
found = true;
|
|
|
|
|
if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL)
|
|
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
|
|
|
|
|
|
|
|
|
fprintf(script, "%s\n", datname);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(dbres);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn_template1);
|
|
|
|
|
|
|
|
|
|
if (script)
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("All non-template0 databases must allow connections, i.e. their\n"
|
|
|
|
|
"pg_database.datallowconn must be true. Your installation contains\n"
|
|
|
|
|
"non-template0 databases with their pg_database.datallowconn set to\n"
|
|
|
|
|
"false. Consider allowing connection for all non-template0 databases\n"
|
|
|
|
|
"or drop the databases which do not allow connections. A list of\n"
|
|
|
|
|
"databases with the problem is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_for_prepared_transactions()
|
|
|
|
|
*
|
|
|
|
|
* Make sure there are no prepared transactions because the storage format
|
|
|
|
|
* might have changed.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_prepared_transactions(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
PGconn *conn = connectToServer(cluster, "template1");
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for prepared transactions");
|
|
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT * "
|
|
|
|
|
"FROM pg_catalog.pg_prepared_xacts");
|
|
|
|
|
|
|
|
|
|
if (PQntuples(res) != 0)
|
|
|
|
|
{
|
|
|
|
|
if (cluster == &old_cluster)
|
|
|
|
|
pg_fatal("The source cluster contains prepared transactions\n");
|
|
|
|
|
else
|
|
|
|
|
pg_fatal("The target cluster contains prepared transactions\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_for_isn_and_int8_passing_mismatch()
|
|
|
|
|
*
|
|
|
|
|
* contrib/isn relies on data type int8, and in 8.4 int8 can now be passed
|
|
|
|
|
* by value. The schema dumps the CREATE TYPE PASSEDBYVALUE setting so
|
|
|
|
|
* it must match for the old and new servers.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_isn_and_int8_passing_mismatch(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for contrib/isn with bigint-passing mismatch");
|
|
|
|
|
|
|
|
|
|
if (old_cluster.controldata.float8_pass_by_value ==
|
|
|
|
|
new_cluster.controldata.float8_pass_by_value)
|
|
|
|
|
{
|
|
|
|
|
/* no mismatch */
|
|
|
|
|
check_ok();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
pg_upgrade: Move all the files generated internally to a subdirectory
Historically, the location of any files generated by pg_upgrade, as of
the per-database logs and internal dumps, has been the current working
directory, leaving all those files behind when using --retain or on a
failure.
Putting all those contents in a targeted subdirectory makes the whole
easier to debug, and simplifies the code in charge of cleaning up the
logs. Note that another reason is that this facilitates the move of
pg_upgrade to TAP with a fixed location for all the logs to grab if the
test fails repeatedly.
Initially, we thought about being able to specify the output directory
with a new option, but we have settled on using a subdirectory located
at the root of the new cluster's data folder, "pg_upgrade_output.d",
instead, as at the end the new data directory is the location of all the
data generated by pg_upgrade. There is a take with group permissions
here though: if the new data folder has been initialized with this
option, we need to create all the files and paths with the correct
permissions or a base backup taken after a pg_upgrade --retain would
fail, meaning that GetDataDirectoryCreatePerm() has to be called before
creating the log paths, before a couple of sanity checks on the clusters
and before getting the socket directory for the cluster's host settings.
The idea of the new location is based on a suggestion from Peter
Eisentraut.
Also thanks to Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson, Tom
Lane and Bruce Momjian for the discussion (in alphabetical order).
Author: Justin Pryzby
Discussion: https://postgr.es/m/20211212025017.GN17618@telsasoft.com
4 years ago
|
|
|
snprintf(output_path, sizeof(output_path), "%s/%s",
|
|
|
|
|
log_opts.basedir,
|
|
|
|
|
"contrib_isn_and_int8_pass_by_value.txt");
|
|
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
int ntups;
|
|
|
|
|
int rowno;
|
|
|
|
|
int i_nspname,
|
|
|
|
|
i_proname;
|
|
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
|
|
|
|
|
|
|
|
|
/* Find any functions coming from contrib/isn */
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT n.nspname, p.proname "
|
|
|
|
|
"FROM pg_catalog.pg_proc p, "
|
|
|
|
|
" pg_catalog.pg_namespace n "
|
|
|
|
|
"WHERE p.pronamespace = n.oid AND "
|
|
|
|
|
" p.probin = '$libdir/isn'");
|
|
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
i_nspname = PQfnumber(res, "nspname");
|
|
|
|
|
i_proname = PQfnumber(res, "proname");
|
|
|
|
|
for (rowno = 0; rowno < ntups; rowno++)
|
|
|
|
|
{
|
|
|
|
|
found = true;
|
|
|
|
|
if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL)
|
Improve error reporting in pg_upgrade's file copying/linking/rewriting.
The previous design for this had copyFile(), linkFile(), and
rewriteVisibilityMap() returning strerror strings, with the caller
producing one-size-fits-all error messages based on that. This made it
impossible to produce messages that described the failures with any degree
of precision, especially not short-read problems since those don't set
errno at all.
Since pg_upgrade has no intention of continuing after any error in this
area, let's fix this by just letting these functions call pg_fatal() for
themselves, making it easy for each point of failure to have a suitable
error message. Taking this approach also allows dropping cleanup code
that was unnecessary and was often rather sloppy about preserving errno.
To not lose relevant info that was reported before, pass in the schema name
and table name of the current table so that they can be included in the
error reports.
An additional problem was the use of getErrorText(), which was flat out
wrong for all but a couple of call sites, because it unconditionally did
"_dosmaperr(GetLastError())" on Windows. That's only appropriate when
reporting an error from a Windows-native API, which only a couple of
the callers were actually doing. Thus, even the reported strerror string
would be unrelated to the actual failure in many cases on Windows.
To fix, get rid of getErrorText() altogether, and just have call sites
do strerror(errno) instead, since that's the way all the rest of our
frontend programs do it. Add back the _dosmaperr() calls in the two
places where that's actually appropriate.
In passing, make assorted messages hew more closely to project style
guidelines, notably by removing initial capitals in not-complete-sentence
primary error messages. (I didn't make any effort to clean up places
I didn't have another reason to touch, though.)
Per discussion of a report from Thomas Kellerer. Back-patch to 9.6,
but no further; given the relative infrequency of reports of problems
here, it's not clear it's worth adapting the patch to older branches.
Patch by me, but with credit to Alvaro Herrera for spotting the issue
with getErrorText's misuse of _dosmaperr().
Discussion: <nsjrbh$8li$1@blaine.gmane.org>
9 years ago
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
|
|
|
|
if (!db_used)
|
|
|
|
|
{
|
|
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
|
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
fprintf(script, " %s.%s\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_nspname),
|
|
|
|
|
PQgetvalue(res, rowno, i_proname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (script)
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains \"contrib/isn\" functions which rely on the\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
9 years ago
|
|
|
"bigint data type. Your old and new clusters pass bigint values\n"
|
|
|
|
|
"differently so this cluster cannot currently be upgraded. You can\n"
|
|
|
|
|
"manually dump databases in the old cluster that use \"contrib/isn\"\n"
|
|
|
|
|
"facilities, drop them, perform the upgrade, and then restore them. A\n"
|
|
|
|
|
"list of the problem functions is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
5 years ago
|
|
|
/*
|
|
|
|
|
* Verify that no user defined postfix operators exist.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_user_defined_postfix_ops(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for user-defined postfix operators");
|
|
|
|
|
|
pg_upgrade: Move all the files generated internally to a subdirectory
Historically, the location of any files generated by pg_upgrade, as of
the per-database logs and internal dumps, has been the current working
directory, leaving all those files behind when using --retain or on a
failure.
Putting all those contents in a targeted subdirectory makes the whole
easier to debug, and simplifies the code in charge of cleaning up the
logs. Note that another reason is that this facilitates the move of
pg_upgrade to TAP with a fixed location for all the logs to grab if the
test fails repeatedly.
Initially, we thought about being able to specify the output directory
with a new option, but we have settled on using a subdirectory located
at the root of the new cluster's data folder, "pg_upgrade_output.d",
instead, as at the end the new data directory is the location of all the
data generated by pg_upgrade. There is a take with group permissions
here though: if the new data folder has been initialized with this
option, we need to create all the files and paths with the correct
permissions or a base backup taken after a pg_upgrade --retain would
fail, meaning that GetDataDirectoryCreatePerm() has to be called before
creating the log paths, before a couple of sanity checks on the clusters
and before getting the socket directory for the cluster's host settings.
The idea of the new location is based on a suggestion from Peter
Eisentraut.
Also thanks to Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson, Tom
Lane and Bruce Momjian for the discussion (in alphabetical order).
Author: Justin Pryzby
Discussion: https://postgr.es/m/20211212025017.GN17618@telsasoft.com
4 years ago
|
|
|
snprintf(output_path, sizeof(output_path), "%s/%s",
|
|
|
|
|
log_opts.basedir,
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
5 years ago
|
|
|
"postfix_ops.txt");
|
|
|
|
|
|
|
|
|
|
/* Find any user defined postfix operators */
|
|
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
int ntups;
|
|
|
|
|
int rowno;
|
|
|
|
|
int i_oproid,
|
|
|
|
|
i_oprnsp,
|
|
|
|
|
i_oprname,
|
|
|
|
|
i_typnsp,
|
|
|
|
|
i_typname;
|
|
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The query below hardcodes FirstNormalObjectId as 16384 rather than
|
|
|
|
|
* interpolating that C #define into the query because, if that
|
|
|
|
|
* #define is ever changed, the cutoff we want to use is the value
|
|
|
|
|
* used by pre-version 14 servers, not that of some future version.
|
|
|
|
|
*/
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT o.oid AS oproid, "
|
|
|
|
|
" n.nspname AS oprnsp, "
|
|
|
|
|
" o.oprname, "
|
|
|
|
|
" tn.nspname AS typnsp, "
|
|
|
|
|
" t.typname "
|
|
|
|
|
"FROM pg_catalog.pg_operator o, "
|
|
|
|
|
" pg_catalog.pg_namespace n, "
|
|
|
|
|
" pg_catalog.pg_type t, "
|
|
|
|
|
" pg_catalog.pg_namespace tn "
|
|
|
|
|
"WHERE o.oprnamespace = n.oid AND "
|
|
|
|
|
" o.oprleft = t.oid AND "
|
|
|
|
|
" t.typnamespace = tn.oid AND "
|
|
|
|
|
" o.oprright = 0 AND "
|
|
|
|
|
" o.oid >= 16384");
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
i_oproid = PQfnumber(res, "oproid");
|
|
|
|
|
i_oprnsp = PQfnumber(res, "oprnsp");
|
|
|
|
|
i_oprname = PQfnumber(res, "oprname");
|
|
|
|
|
i_typnsp = PQfnumber(res, "typnsp");
|
|
|
|
|
i_typname = PQfnumber(res, "typname");
|
|
|
|
|
for (rowno = 0; rowno < ntups; rowno++)
|
|
|
|
|
{
|
|
|
|
|
found = true;
|
|
|
|
|
if (script == NULL &&
|
|
|
|
|
(script = fopen_priv(output_path, "w")) == NULL)
|
|
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
|
|
|
|
if (!db_used)
|
|
|
|
|
{
|
|
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
|
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
fprintf(script, " (oid=%s) %s.%s (%s.%s, NONE)\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_oproid),
|
|
|
|
|
PQgetvalue(res, rowno, i_oprnsp),
|
|
|
|
|
PQgetvalue(res, rowno, i_oprname),
|
|
|
|
|
PQgetvalue(res, rowno, i_typnsp),
|
|
|
|
|
PQgetvalue(res, rowno, i_typname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (script)
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains user-defined postfix operators, which are not\n"
|
|
|
|
|
"supported anymore. Consider dropping the postfix operators and replacing\n"
|
|
|
|
|
"them with prefix operators or function calls.\n"
|
|
|
|
|
"A list of user-defined postfix operators is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_for_incompatible_polymorphics()
|
|
|
|
|
*
|
|
|
|
|
* Make sure nothing is using old polymorphic functions with
|
|
|
|
|
* anyarray/anyelement rather than the new anycompatible variants.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_incompatible_polymorphics(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
PQExpBufferData old_polymorphics;
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for incompatible polymorphic functions");
|
|
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path), "%s/%s",
|
|
|
|
|
log_opts.basedir,
|
|
|
|
|
"incompatible_polymorphics.txt");
|
|
|
|
|
|
|
|
|
|
/* The set of problematic functions varies a bit in different versions */
|
|
|
|
|
initPQExpBuffer(&old_polymorphics);
|
|
|
|
|
|
|
|
|
|
appendPQExpBufferStr(&old_polymorphics,
|
|
|
|
|
"'array_append(anyarray,anyelement)'"
|
|
|
|
|
", 'array_cat(anyarray,anyarray)'"
|
|
|
|
|
", 'array_prepend(anyelement,anyarray)'");
|
|
|
|
|
|
|
|
|
|
if (GET_MAJOR_VERSION(cluster->major_version) >= 903)
|
|
|
|
|
appendPQExpBufferStr(&old_polymorphics,
|
|
|
|
|
", 'array_remove(anyarray,anyelement)'"
|
|
|
|
|
", 'array_replace(anyarray,anyelement,anyelement)'");
|
|
|
|
|
|
|
|
|
|
if (GET_MAJOR_VERSION(cluster->major_version) >= 905)
|
|
|
|
|
appendPQExpBufferStr(&old_polymorphics,
|
|
|
|
|
", 'array_position(anyarray,anyelement)'"
|
|
|
|
|
", 'array_position(anyarray,anyelement,integer)'"
|
|
|
|
|
", 'array_positions(anyarray,anyelement)'"
|
|
|
|
|
", 'width_bucket(anyelement,anyarray)'");
|
|
|
|
|
|
|
|
|
|
for (int dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
|
|
|
|
int ntups;
|
|
|
|
|
int i_objkind,
|
|
|
|
|
i_objname;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The query below hardcodes FirstNormalObjectId as 16384 rather than
|
|
|
|
|
* interpolating that C #define into the query because, if that
|
|
|
|
|
* #define is ever changed, the cutoff we want to use is the value
|
|
|
|
|
* used by pre-version 14 servers, not that of some future version.
|
|
|
|
|
*/
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
/* Aggregate transition functions */
|
|
|
|
|
"SELECT 'aggregate' AS objkind, p.oid::regprocedure::text AS objname "
|
|
|
|
|
"FROM pg_proc AS p "
|
|
|
|
|
"JOIN pg_aggregate AS a ON a.aggfnoid=p.oid "
|
|
|
|
|
"JOIN pg_proc AS transfn ON transfn.oid=a.aggtransfn "
|
|
|
|
|
"WHERE p.oid >= 16384 "
|
|
|
|
|
"AND a.aggtransfn = ANY(ARRAY[%s]::regprocedure[]) "
|
|
|
|
|
"AND a.aggtranstype = ANY(ARRAY['anyarray', 'anyelement']::regtype[]) "
|
|
|
|
|
|
|
|
|
|
/* Aggregate final functions */
|
|
|
|
|
"UNION ALL "
|
|
|
|
|
"SELECT 'aggregate' AS objkind, p.oid::regprocedure::text AS objname "
|
|
|
|
|
"FROM pg_proc AS p "
|
|
|
|
|
"JOIN pg_aggregate AS a ON a.aggfnoid=p.oid "
|
|
|
|
|
"JOIN pg_proc AS finalfn ON finalfn.oid=a.aggfinalfn "
|
|
|
|
|
"WHERE p.oid >= 16384 "
|
|
|
|
|
"AND a.aggfinalfn = ANY(ARRAY[%s]::regprocedure[]) "
|
|
|
|
|
"AND a.aggtranstype = ANY(ARRAY['anyarray', 'anyelement']::regtype[]) "
|
|
|
|
|
|
|
|
|
|
/* Operators */
|
|
|
|
|
"UNION ALL "
|
|
|
|
|
"SELECT 'operator' AS objkind, op.oid::regoperator::text AS objname "
|
|
|
|
|
"FROM pg_operator AS op "
|
|
|
|
|
"WHERE op.oid >= 16384 "
|
|
|
|
|
"AND oprcode = ANY(ARRAY[%s]::regprocedure[]) "
|
|
|
|
|
"AND oprleft = ANY(ARRAY['anyarray', 'anyelement']::regtype[]);",
|
|
|
|
|
old_polymorphics.data,
|
|
|
|
|
old_polymorphics.data,
|
|
|
|
|
old_polymorphics.data);
|
|
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
|
|
|
|
|
i_objkind = PQfnumber(res, "objkind");
|
|
|
|
|
i_objname = PQfnumber(res, "objname");
|
|
|
|
|
|
|
|
|
|
for (int rowno = 0; rowno < ntups; rowno++)
|
|
|
|
|
{
|
|
|
|
|
if (script == NULL &&
|
|
|
|
|
(script = fopen_priv(output_path, "w")) == NULL)
|
|
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
|
|
|
|
if (!db_used)
|
|
|
|
|
{
|
|
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
|
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fprintf(script, " %s: %s\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_objkind),
|
|
|
|
|
PQgetvalue(res, rowno, i_objname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (script)
|
|
|
|
|
{
|
|
|
|
|
fclose(script);
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains user-defined objects that refer to internal\n"
|
|
|
|
|
"polymorphic functions with arguments of type 'anyarray' or 'anyelement'.\n"
|
|
|
|
|
"These user-defined objects must be dropped before upgrading and restored\n"
|
|
|
|
|
"afterwards, changing them to refer to the new corresponding functions with\n"
|
|
|
|
|
"arguments of type 'anycompatiblearray' and 'anycompatible'.\n"
|
|
|
|
|
"A list of the problematic objects is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
|
|
|
|
|
termPQExpBuffer(&old_polymorphics);
|
|
|
|
|
}
|
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
/*
|
|
|
|
|
* Verify that no tables are declared WITH OIDS.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_tables_with_oids(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for tables WITH OIDS");
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
|
pg_upgrade: Move all the files generated internally to a subdirectory
Historically, the location of any files generated by pg_upgrade, as of
the per-database logs and internal dumps, has been the current working
directory, leaving all those files behind when using --retain or on a
failure.
Putting all those contents in a targeted subdirectory makes the whole
easier to debug, and simplifies the code in charge of cleaning up the
logs. Note that another reason is that this facilitates the move of
pg_upgrade to TAP with a fixed location for all the logs to grab if the
test fails repeatedly.
Initially, we thought about being able to specify the output directory
with a new option, but we have settled on using a subdirectory located
at the root of the new cluster's data folder, "pg_upgrade_output.d",
instead, as at the end the new data directory is the location of all the
data generated by pg_upgrade. There is a take with group permissions
here though: if the new data folder has been initialized with this
option, we need to create all the files and paths with the correct
permissions or a base backup taken after a pg_upgrade --retain would
fail, meaning that GetDataDirectoryCreatePerm() has to be called before
creating the log paths, before a couple of sanity checks on the clusters
and before getting the socket directory for the cluster's host settings.
The idea of the new location is based on a suggestion from Peter
Eisentraut.
Also thanks to Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson, Tom
Lane and Bruce Momjian for the discussion (in alphabetical order).
Author: Justin Pryzby
Discussion: https://postgr.es/m/20211212025017.GN17618@telsasoft.com
4 years ago
|
|
|
snprintf(output_path, sizeof(output_path), "%s/%s",
|
|
|
|
|
log_opts.basedir,
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
"tables_with_oids.txt");
|
|
|
|
|
|
|
|
|
|
/* Find any tables declared WITH OIDS */
|
|
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
int ntups;
|
|
|
|
|
int rowno;
|
|
|
|
|
int i_nspname,
|
|
|
|
|
i_relname;
|
|
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
|
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT n.nspname, c.relname "
|
|
|
|
|
"FROM pg_catalog.pg_class c, "
|
|
|
|
|
" pg_catalog.pg_namespace n "
|
|
|
|
|
"WHERE c.relnamespace = n.oid AND "
|
|
|
|
|
" c.relhasoids AND"
|
|
|
|
|
" n.nspname NOT IN ('pg_catalog')");
|
|
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
i_nspname = PQfnumber(res, "nspname");
|
|
|
|
|
i_relname = PQfnumber(res, "relname");
|
|
|
|
|
for (rowno = 0; rowno < ntups; rowno++)
|
|
|
|
|
{
|
|
|
|
|
found = true;
|
|
|
|
|
if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL)
|
|
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
|
|
|
|
if (!db_used)
|
|
|
|
|
{
|
|
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
fprintf(script, " %s.%s\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_nspname),
|
|
|
|
|
PQgetvalue(res, rowno, i_relname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (script)
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains tables declared WITH OIDS, which is not\n"
|
|
|
|
|
"supported anymore. Consider removing the oid column using\n"
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
" ALTER TABLE ... SET WITHOUT OIDS;\n"
|
|
|
|
|
"A list of tables with the problem is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
Fix some more omissions in pg_upgrade's tests for non-upgradable types.
Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges. However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c. (The division
of responsibility between those files is less than clear...)
In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable. It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.
To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
5 years ago
|
|
|
/*
|
|
|
|
|
* check_for_composite_data_type_usage()
|
|
|
|
|
* Check for system-defined composite types used in user tables.
|
|
|
|
|
*
|
|
|
|
|
* The OIDs of rowtypes of system catalogs and information_schema views
|
|
|
|
|
* can change across major versions; unlike user-defined types, we have
|
|
|
|
|
* no mechanism for forcing them to be the same in the new cluster.
|
|
|
|
|
* Hence, if any user table uses one, that's problematic for pg_upgrade.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_composite_data_type_usage(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
bool found;
|
|
|
|
|
Oid firstUserOid;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
char *base_query;
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for system-defined composite types in user tables");
|
|
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path), "tables_using_composite.txt");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Look for composite types that were made during initdb *or* belong to
|
|
|
|
|
* information_schema; that's important in case information_schema was
|
|
|
|
|
* dropped and reloaded.
|
|
|
|
|
*
|
|
|
|
|
* The cutoff OID here should match the source cluster's value of
|
|
|
|
|
* FirstNormalObjectId. We hardcode it rather than using that C #define
|
|
|
|
|
* because, if that #define is ever changed, our own version's value is
|
|
|
|
|
* NOT what to use. Eventually we may need a test on the source cluster's
|
|
|
|
|
* version to select the correct value.
|
|
|
|
|
*/
|
|
|
|
|
firstUserOid = 16384;
|
|
|
|
|
|
|
|
|
|
base_query = psprintf("SELECT t.oid FROM pg_catalog.pg_type t "
|
|
|
|
|
"LEFT JOIN pg_catalog.pg_namespace n ON t.typnamespace = n.oid "
|
|
|
|
|
" WHERE typtype = 'c' AND (t.oid < %u OR nspname = 'information_schema')",
|
|
|
|
|
firstUserOid);
|
|
|
|
|
|
|
|
|
|
found = check_for_data_types_usage(cluster, base_query, output_path);
|
|
|
|
|
|
|
|
|
|
free(base_query);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains system-defined composite type(s) in user tables.\n"
|
|
|
|
|
"These type OIDs are not stable across PostgreSQL versions,\n"
|
|
|
|
|
"so this cluster cannot currently be upgraded. You can\n"
|
|
|
|
|
"drop the problem columns and restart the upgrade.\n"
|
|
|
|
|
"A list of the problem columns is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_for_reg_data_type_usage()
|
|
|
|
|
* pg_upgrade only preserves these system values:
|
|
|
|
|
* pg_class.oid
|
|
|
|
|
* pg_type.oid
|
|
|
|
|
* pg_enum.oid
|
|
|
|
|
*
|
|
|
|
|
* Many of the reg* data types reference system catalog info that is
|
|
|
|
|
* not preserved, and hence these data types cannot be used in user
|
|
|
|
|
* tables upgraded by pg_upgrade.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_reg_data_type_usage(ClusterInfo *cluster)
|
|
|
|
|
{
|
Fix some more omissions in pg_upgrade's tests for non-upgradable types.
Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges. However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c. (The division
of responsibility between those files is less than clear...)
In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable. It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.
To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
5 years ago
|
|
|
bool found;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for reg* data types in user tables");
|
|
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path), "tables_using_reg.txt");
|
|
|
|
|
|
Fix some more omissions in pg_upgrade's tests for non-upgradable types.
Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges. However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c. (The division
of responsibility between those files is less than clear...)
In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable. It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.
To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
5 years ago
|
|
|
/*
|
|
|
|
|
* Note: older servers will not have all of these reg* types, so we have
|
|
|
|
|
* to write the query like this rather than depending on casts to regtype.
|
|
|
|
|
*/
|
|
|
|
|
found = check_for_data_types_usage(cluster,
|
|
|
|
|
"SELECT oid FROM pg_catalog.pg_type t "
|
|
|
|
|
"WHERE t.typnamespace = "
|
|
|
|
|
" (SELECT oid FROM pg_catalog.pg_namespace "
|
|
|
|
|
" WHERE nspname = 'pg_catalog') "
|
|
|
|
|
" AND t.typname IN ( "
|
|
|
|
|
/* pg_class.oid is preserved, so 'regclass' is OK */
|
|
|
|
|
" 'regcollation', "
|
|
|
|
|
" 'regconfig', "
|
|
|
|
|
" 'regdictionary', "
|
|
|
|
|
" 'regnamespace', "
|
|
|
|
|
" 'regoper', "
|
|
|
|
|
" 'regoperator', "
|
|
|
|
|
" 'regproc', "
|
|
|
|
|
" 'regprocedure' "
|
|
|
|
|
/* pg_authid.oid is preserved, so 'regrole' is OK */
|
|
|
|
|
/* pg_type.oid is (mostly) preserved, so 'regtype' is OK */
|
|
|
|
|
" )",
|
|
|
|
|
output_path);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains one of the reg* data types in user tables.\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
9 years ago
|
|
|
"These data types reference system OIDs that are not preserved by\n"
|
|
|
|
|
"pg_upgrade, so this cluster cannot currently be upgraded. You can\n"
|
|
|
|
|
"drop the problem columns and restart the upgrade.\n"
|
|
|
|
|
"A list of the problem columns is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_for_jsonb_9_4_usage()
|
|
|
|
|
*
|
|
|
|
|
* JSONB changed its storage format during 9.4 beta, so check for it.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_jsonb_9_4_usage(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for incompatible \"jsonb\" data type");
|
|
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path), "tables_using_jsonb.txt");
|
|
|
|
|
|
Fix some more omissions in pg_upgrade's tests for non-upgradable types.
Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges. However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c. (The division
of responsibility between those files is less than clear...)
In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable. It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.
To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
5 years ago
|
|
|
if (check_for_data_type_usage(cluster, "pg_catalog.jsonb", output_path))
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains the \"jsonb\" data type in user tables.\n"
|
|
|
|
|
"The internal format of \"jsonb\" changed during 9.4 beta so this\n"
|
|
|
|
|
"cluster cannot currently be upgraded. You can\n"
|
|
|
|
|
"drop the problem columns and restart the upgrade.\n"
|
|
|
|
|
"A list of the problem columns is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check_for_pg_role_prefix()
|
|
|
|
|
*
|
|
|
|
|
* Versions older than 9.6 should not have any pg_* roles
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_pg_role_prefix(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
PGconn *conn = connectToServer(cluster, "template1");
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for roles starting with \"pg_\"");
|
|
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT * "
|
|
|
|
|
"FROM pg_catalog.pg_roles "
|
|
|
|
|
"WHERE rolname ~ '^pg_'");
|
|
|
|
|
|
|
|
|
|
if (PQntuples(res) != 0)
|
|
|
|
|
{
|
|
|
|
|
if (cluster == &old_cluster)
|
|
|
|
|
pg_fatal("The source cluster contains roles starting with \"pg_\"\n");
|
|
|
|
|
else
|
|
|
|
|
pg_fatal("The target cluster contains roles starting with \"pg_\"\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Verify that no user-defined encoding conversions exist.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
check_for_user_defined_encoding_conversions(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
|
|
|
|
prep_status("Checking for user-defined encoding conversions");
|
|
|
|
|
|
pg_upgrade: Move all the files generated internally to a subdirectory
Historically, the location of any files generated by pg_upgrade, as of
the per-database logs and internal dumps, has been the current working
directory, leaving all those files behind when using --retain or on a
failure.
Putting all those contents in a targeted subdirectory makes the whole
easier to debug, and simplifies the code in charge of cleaning up the
logs. Note that another reason is that this facilitates the move of
pg_upgrade to TAP with a fixed location for all the logs to grab if the
test fails repeatedly.
Initially, we thought about being able to specify the output directory
with a new option, but we have settled on using a subdirectory located
at the root of the new cluster's data folder, "pg_upgrade_output.d",
instead, as at the end the new data directory is the location of all the
data generated by pg_upgrade. There is a take with group permissions
here though: if the new data folder has been initialized with this
option, we need to create all the files and paths with the correct
permissions or a base backup taken after a pg_upgrade --retain would
fail, meaning that GetDataDirectoryCreatePerm() has to be called before
creating the log paths, before a couple of sanity checks on the clusters
and before getting the socket directory for the cluster's host settings.
The idea of the new location is based on a suggestion from Peter
Eisentraut.
Also thanks to Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson, Tom
Lane and Bruce Momjian for the discussion (in alphabetical order).
Author: Justin Pryzby
Discussion: https://postgr.es/m/20211212025017.GN17618@telsasoft.com
4 years ago
|
|
|
snprintf(output_path, sizeof(output_path), "%s/%s",
|
|
|
|
|
log_opts.basedir,
|
|
|
|
|
"encoding_conversions.txt");
|
|
|
|
|
|
|
|
|
|
/* Find any user defined encoding conversions */
|
|
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
int ntups;
|
|
|
|
|
int rowno;
|
|
|
|
|
int i_conoid,
|
|
|
|
|
i_conname,
|
|
|
|
|
i_nspname;
|
|
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The query below hardcodes FirstNormalObjectId as 16384 rather than
|
|
|
|
|
* interpolating that C #define into the query because, if that
|
|
|
|
|
* #define is ever changed, the cutoff we want to use is the value
|
|
|
|
|
* used by pre-version 14 servers, not that of some future version.
|
|
|
|
|
*/
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT c.oid as conoid, c.conname, n.nspname "
|
|
|
|
|
"FROM pg_catalog.pg_conversion c, "
|
|
|
|
|
" pg_catalog.pg_namespace n "
|
|
|
|
|
"WHERE c.connamespace = n.oid AND "
|
|
|
|
|
" c.oid >= 16384");
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
i_conoid = PQfnumber(res, "conoid");
|
|
|
|
|
i_conname = PQfnumber(res, "conname");
|
|
|
|
|
i_nspname = PQfnumber(res, "nspname");
|
|
|
|
|
for (rowno = 0; rowno < ntups; rowno++)
|
|
|
|
|
{
|
|
|
|
|
found = true;
|
|
|
|
|
if (script == NULL &&
|
|
|
|
|
(script = fopen_priv(output_path, "w")) == NULL)
|
|
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
|
|
|
|
if (!db_used)
|
|
|
|
|
{
|
|
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
|
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
fprintf(script, " (oid=%s) %s.%s\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_conoid),
|
|
|
|
|
PQgetvalue(res, rowno, i_nspname),
|
|
|
|
|
PQgetvalue(res, rowno, i_conname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (script)
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
|
|
|
|
pg_fatal("Your installation contains user-defined encoding conversions.\n"
|
|
|
|
|
"The conversion function parameters changed in PostgreSQL version 14\n"
|
|
|
|
|
"so this cluster cannot currently be upgraded. You can remove the\n"
|
|
|
|
|
"encoding conversions in the old cluster and restart the upgrade.\n"
|
|
|
|
|
"A list of user-defined encoding conversions is in the file:\n"
|
|
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* get_canonical_locale_name
|
|
|
|
|
*
|
|
|
|
|
* Send the locale name to the system, and hope we get back a canonical
|
|
|
|
|
* version. This should match the backend's check_locale() function.
|
|
|
|
|
*/
|
|
|
|
|
static char *
|
|
|
|
|
get_canonical_locale_name(int category, const char *locale)
|
|
|
|
|
{
|
|
|
|
|
char *save;
|
|
|
|
|
char *res;
|
|
|
|
|
|
|
|
|
|
/* get the current setting, so we can restore it. */
|
|
|
|
|
save = setlocale(category, NULL);
|
|
|
|
|
if (!save)
|
|
|
|
|
pg_fatal("failed to get the current locale\n");
|
|
|
|
|
|
|
|
|
|
/* 'save' may be pointing at a modifiable scratch variable, so copy it. */
|
|
|
|
|
save = pg_strdup(save);
|
|
|
|
|
|
|
|
|
|
/* set the locale with setlocale, to see if it accepts it. */
|
|
|
|
|
res = setlocale(category, locale);
|
|
|
|
|
|
|
|
|
|
if (!res)
|
|
|
|
|
pg_fatal("failed to get system locale name for \"%s\"\n", locale);
|
|
|
|
|
|
|
|
|
|
res = pg_strdup(res);
|
|
|
|
|
|
|
|
|
|
/* restore old value. */
|
|
|
|
|
if (!setlocale(category, save))
|
|
|
|
|
pg_fatal("failed to restore old locale \"%s\"\n", save);
|
|
|
|
|
|
|
|
|
|
pg_free(save);
|
|
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
