2010-05-12 04:19:11 +02:00
|
|
|
/*
|
|
|
|
|
* check.c
|
|
|
|
|
*
|
|
|
|
|
* server checks and output routines
|
2010-07-03 16:23:14 +02:00
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Copyright (c) 2010-2020, PostgreSQL Global Development Group
|
2015-03-11 03:33:25 +01:00
|
|
|
* src/bin/pg_upgrade/check.c
|
2010-05-12 04:19:11 +02:00
|
|
|
*/
|
|
|
|
|
|
Create libpgcommon, and move pg_malloc et al to it
libpgcommon is a new static library to allow sharing code among the
various frontend programs and backend; this lets us eliminate duplicate
implementations of common routines. We avoid libpgport, because that's
intended as a place for porting issues; per discussion, it seems better
to keep them separate.
The first use case, and the only implemented by this patch, is pg_malloc
and friends, which many frontend programs were already using.
At the same time, we can use this to provide palloc emulation functions
for the frontend; this way, some palloc-using files in the backend can
also be used by the frontend cleanly. To do this, we change palloc() in
the backend to be a function instead of a macro on top of
MemoryContextAlloc(). This was previously believed to cause loss of
performance, but this implementation has been tweaked by Tom and Andres
so that on modern compilers it provides a slight improvement over the
previous one.
This lets us clean up some places that were already with
localized hacks.
Most of the pg_malloc/palloc changes in this patch were authored by
Andres Freund. Zoltán Böszörményi also independently provided a form of
that. libpgcommon infrastructure was authored by Álvaro.
2013-02-12 14:33:40 +01:00
|
|
|
#include "postgres_fe.h"
|
2011-08-27 03:16:24 +02:00
|
|
|
|
2018-04-08 19:59:52 +02:00
|
|
|
#include "catalog/pg_authid_d.h"
|
2016-08-08 16:07:46 +02:00
|
|
|
#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
2014-01-31 01:07:06 +01:00
|
|
|
#include "mb/pg_wchar.h"
|
2010-05-12 04:19:11 +02:00
|
|
|
#include "pg_upgrade.h"
|
|
|
|
|
|
2011-04-20 03:00:29 +02:00
|
|
|
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.
2014-10-10 08:59:44 +02:00
|
|
|
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);
|
2014-08-04 17:56:16 +02:00
|
|
|
static void check_is_install_user(ClusterInfo *cluster);
|
2015-05-16 06:10:03 +02:00
|
|
|
static void check_proper_datallowconn(ClusterInfo *cluster);
|
2011-06-14 20:53:35 +02:00
|
|
|
static void check_for_prepared_transactions(ClusterInfo *cluster);
|
2011-01-01 18:06:36 +01:00
|
|
|
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
2020-09-18 01:38:05 +02:00
|
|
|
static void check_for_user_defined_postfix_ops(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
2018-11-21 00:36:57 +01:00
|
|
|
static void check_for_tables_with_oids(ClusterInfo *cluster);
|
2011-01-01 18:06:36 +01:00
|
|
|
static void check_for_reg_data_type_usage(ClusterInfo *cluster);
|
2014-09-30 02:19:59 +02:00
|
|
|
static void check_for_jsonb_9_4_usage(ClusterInfo *cluster);
|
2016-04-08 22:56:27 +02:00
|
|
|
static void check_for_pg_role_prefix(ClusterInfo *cluster);
|
2012-10-02 17:42:34 +02:00
|
|
|
static char *get_canonical_locale_name(int category, const char *locale);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
|
2012-09-04 00:06:47 +02:00
|
|
|
/*
|
|
|
|
|
* fix_path_separator
|
|
|
|
|
* For non-Windows, just return the argument.
|
|
|
|
|
* For Windows convert any forward slash to a backslash
|
2013-05-29 22:58:43 +02:00
|
|
|
* such as is suitable for arguments to builtin commands
|
2012-09-04 00:06:47 +02:00
|
|
|
* like RMDIR and DEL.
|
|
|
|
|
*/
|
2012-09-04 04:59:19 +02:00
|
|
|
static char *
|
|
|
|
|
fix_path_separator(char *path)
|
2012-09-04 00:06:47 +02:00
|
|
|
{
|
|
|
|
|
#ifdef WIN32
|
|
|
|
|
|
2013-05-29 22:58:43 +02:00
|
|
|
char *result;
|
|
|
|
|
char *c;
|
2012-09-04 00:06:47 +02:00
|
|
|
|
|
|
|
|
result = pg_strdup(path);
|
|
|
|
|
|
|
|
|
|
for (c = result; *c != '\0'; c++)
|
|
|
|
|
if (*c == '/')
|
|
|
|
|
*c = '\\';
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
return path;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
void
|
2013-01-24 21:20:11 +01:00
|
|
|
output_check_banner(bool live_check)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2013-01-24 21:20:11 +01:00
|
|
|
if (user_opts.check && live_check)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2017-08-23 02:32:17 +02:00
|
|
|
pg_log(PG_REPORT,
|
|
|
|
|
"Performing Consistency Checks on Old Live Server\n"
|
|
|
|
|
"------------------------------------------------\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2017-08-23 02:32:17 +02:00
|
|
|
pg_log(PG_REPORT,
|
|
|
|
|
"Performing Consistency Checks\n"
|
|
|
|
|
"-----------------------------\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2014-08-26 02:05:07 +02:00
|
|
|
check_and_dump_old_cluster(bool live_check)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
|
/* -- OLD -- */
|
|
|
|
|
|
|
|
|
|
if (!live_check)
|
2013-01-24 21:20:11 +01:00
|
|
|
start_postmaster(&old_cluster, true);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
/* Extract a list of databases and tables from the old cluster */
|
2011-01-01 18:06:36 +01:00
|
|
|
get_db_and_rel_infos(&old_cluster);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
init_tablespaces();
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
get_loadable_libraries();
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check for various failure cases
|
|
|
|
|
*/
|
2014-08-04 17:56:16 +02:00
|
|
|
check_is_install_user(&old_cluster);
|
2015-05-16 06:10:03 +02:00
|
|
|
check_proper_datallowconn(&old_cluster);
|
2011-06-14 20:53:35 +02:00
|
|
|
check_for_prepared_transactions(&old_cluster);
|
2011-01-01 18:06:36 +01:00
|
|
|
check_for_reg_data_type_usage(&old_cluster);
|
|
|
|
|
check_for_isn_and_int8_passing_mismatch(&old_cluster);
|
2016-04-08 22:56:27 +02:00
|
|
|
|
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
2020-09-18 01:38:05 +02:00
|
|
|
/*
|
|
|
|
|
* 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);
|
|
|
|
|
|
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
2018-11-21 00:36:57 +01:00
|
|
|
/*
|
|
|
|
|
* 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
2019-10-14 22:31:56 +02:00
|
|
|
/*
|
|
|
|
|
* 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);
|
|
|
|
|
|
2017-05-19 22:49:38 +02:00
|
|
|
/*
|
|
|
|
|
* 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
2017-01-25 15:17:18 +01:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 906)
|
2017-05-19 22:49:38 +02:00
|
|
|
{
|
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
2017-01-25 15:17:18 +01:00
|
|
|
old_9_6_check_for_unknown_data_type_usage(&old_cluster);
|
2017-05-19 22:49:38 +02:00
|
|
|
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
2017-01-25 15:17:18 +01:00
|
|
|
|
2016-04-08 22:56:27 +02:00
|
|
|
/* 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);
|
|
|
|
|
|
2014-09-30 02:19:59 +02:00
|
|
|
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);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2014-05-14 22:26:06 +02:00
|
|
|
/* Pre-PG 9.4 had a different 'line' data type internal format */
|
2014-05-15 03:13:59 +02:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 903)
|
2014-05-14 22:26:06 +02:00
|
|
|
old_9_3_check_for_line_data_type_usage(&old_cluster);
|
|
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
/* Pre-PG 9.0 had no large object permissions */
|
2010-10-19 23:38:16 +02:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 804)
|
2011-01-01 18:06:36 +01:00
|
|
|
new_9_0_populate_pg_largeobject_metadata(&old_cluster, true);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* While not a check option, we do this now because this is the only time
|
|
|
|
|
* the old server is running.
|
|
|
|
|
*/
|
2010-10-19 23:38:16 +02:00
|
|
|
if (!user_opts.check)
|
|
|
|
|
generate_old_dump();
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
if (!live_check)
|
2011-04-26 02:17:48 +02:00
|
|
|
stop_postmaster(false);
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2010-10-19 23:38:16 +02:00
|
|
|
check_new_cluster(void)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2011-04-20 03:00:29 +02:00
|
|
|
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.
2014-10-10 08:59:44 +02:00
|
|
|
check_databases_are_compatible();
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
check_loadable_libraries();
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2018-11-07 18:05:54 +01:00
|
|
|
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;
|
|
|
|
|
}
|
2012-06-13 18:19:18 +02:00
|
|
|
|
2014-08-04 17:56:16 +02:00
|
|
|
check_is_install_user(&new_cluster);
|
2013-05-29 22:58:43 +02:00
|
|
|
|
2012-06-13 18:19:18 +02:00
|
|
|
check_for_prepared_transactions(&new_cluster);
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2010-10-19 23:38:16 +02:00
|
|
|
report_clusters_compatible(void)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2010-10-19 23:38:16 +02:00
|
|
|
if (user_opts.check)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2010-10-19 23:38:16 +02:00
|
|
|
pg_log(PG_REPORT, "\n*Clusters are compatible*\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
/* stops new cluster */
|
2011-04-26 02:17:48 +02:00
|
|
|
stop_postmaster(false);
|
2011-04-06 22:00:44 +02:00
|
|
|
exit(0);
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
pg_log(PG_REPORT, "\n"
|
2012-03-06 03:19:54 +01:00
|
|
|
"If pg_upgrade fails after this point, you must re-initdb the\n"
|
|
|
|
|
"new cluster before continuing.\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2017-06-20 19:20:02 +02:00
|
|
|
issue_warnings_and_set_wal_level(void)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2017-06-20 19:20:02 +02:00
|
|
|
/*
|
2017-06-21 20:09:24 +02:00
|
|
|
* 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'.
|
2017-06-20 19:20:02 +02:00
|
|
|
*/
|
|
|
|
|
start_postmaster(&new_cluster, true);
|
|
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
/* Create dummy large object permissions for old < PG 9.0? */
|
2010-10-19 23:38:16 +02:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 804)
|
2011-01-01 18:06:36 +01:00
|
|
|
new_9_0_populate_pg_largeobject_metadata(&new_cluster, false);
|
2017-05-19 22:49:38 +02:00
|
|
|
|
|
|
|
|
/* 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);
|
2017-06-20 19:20:02 +02:00
|
|
|
|
|
|
|
|
stop_postmaster(false);
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2012-03-16 23:54:11 +01:00
|
|
|
output_completion_banner(char *analyze_script_file_name,
|
|
|
|
|
char *deletion_script_file_name)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2010-12-15 13:11:31 +01:00
|
|
|
/* Did we copy the free space files? */
|
2010-10-19 23:38:16 +02:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) >= 804)
|
|
|
|
|
pg_log(PG_REPORT,
|
2012-03-16 23:54:11 +01:00
|
|
|
"Optimizer statistics are not transferred by pg_upgrade so,\n"
|
|
|
|
|
"once you start the new server, consider running:\n"
|
|
|
|
|
" %s\n\n", analyze_script_file_name);
|
2010-05-12 04:19:11 +02:00
|
|
|
else
|
2010-10-19 23:38:16 +02:00
|
|
|
pg_log(PG_REPORT,
|
2011-07-12 06:13:51 +02:00
|
|
|
"Optimizer statistics and free space information are not transferred\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
2017-06-21 21:35:54 +02:00
|
|
|
"by pg_upgrade so, once you start the new server, consider running:\n"
|
2012-03-16 23:54:11 +01:00
|
|
|
" %s\n\n", analyze_script_file_name);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2013-02-14 16:53:03 +01:00
|
|
|
|
|
|
|
|
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
2017-06-21 21:35:54 +02:00
|
|
|
"Running this script will delete the old cluster's data files:\n"
|
2013-02-14 16:53:03 +01:00
|
|
|
" %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
2017-06-21 21:35:54 +02:00
|
|
|
"Could not create a script to delete the old cluster's data files\n"
|
2016-06-10 00:02:36 +02:00
|
|
|
"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");
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2010-10-19 23:38:16 +02:00
|
|
|
check_cluster_versions(void)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
2011-06-23 02:48:34 +02:00
|
|
|
prep_status("Checking cluster versions");
|
|
|
|
|
|
2017-11-16 17:16:53 +01:00
|
|
|
/* cluster versions should already have been obtained */
|
|
|
|
|
Assert(old_cluster.major_version != 0);
|
|
|
|
|
Assert(new_cluster.major_version != 0);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2011-04-10 17:42:00 +02:00
|
|
|
/*
|
|
|
|
|
* We allow upgrades from/to the same major version for alpha/beta
|
|
|
|
|
* upgrades
|
|
|
|
|
*/
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2014-08-26 02:05:07 +02:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) < 804)
|
|
|
|
|
pg_fatal("This utility can only upgrade from PostgreSQL version 8.4 and later.\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
/* Only current PG version is supported as a target */
|
2010-10-19 23:38:16 +02:00
|
|
|
if (GET_MAJOR_VERSION(new_cluster.major_version) != GET_MAJOR_VERSION(PG_VERSION_NUM))
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("This utility can only upgrade to PostgreSQL version %s.\n",
|
2014-05-06 18:12:18 +02:00
|
|
|
PG_MAJORVERSION);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
/*
|
2014-07-01 01:55:55 +02:00
|
|
|
* 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.
|
2010-05-12 04:19:11 +02:00
|
|
|
*/
|
2010-10-19 23:38:16 +02:00
|
|
|
if (old_cluster.major_version > new_cluster.major_version)
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("This utility cannot be used to downgrade to older major PostgreSQL versions.\n");
|
2011-06-23 02:48:34 +02:00
|
|
|
|
|
|
|
|
/* Ensure binaries match the designated data directories */
|
|
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) !=
|
|
|
|
|
GET_MAJOR_VERSION(old_cluster.bin_version))
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("Old cluster data and binary directories are from different major versions.\n");
|
2011-06-23 02:48:34 +02:00
|
|
|
if (GET_MAJOR_VERSION(new_cluster.major_version) !=
|
|
|
|
|
GET_MAJOR_VERSION(new_cluster.bin_version))
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("New cluster data and binary directories are from different major versions.\n");
|
2011-06-23 02:48:34 +02:00
|
|
|
|
|
|
|
|
check_ok();
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2010-10-19 23:38:16 +02:00
|
|
|
check_cluster_compatibility(bool live_check)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
|
/* get/check pg_control data of servers */
|
2010-10-19 23:38:16 +02:00
|
|
|
get_control_data(&old_cluster, live_check);
|
|
|
|
|
get_control_data(&new_cluster, false);
|
|
|
|
|
check_control_data(&old_cluster.controldata, &new_cluster.controldata);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2012-09-04 04:15:09 +02:00
|
|
|
/* We read the real port number for PG >= 9.1 */
|
|
|
|
|
if (live_check && GET_MAJOR_VERSION(old_cluster.major_version) < 901 &&
|
|
|
|
|
old_cluster.port == DEF_PGUPORT)
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("When checking a pre-PG 9.1 live old server, "
|
2014-05-06 18:12:18 +02:00
|
|
|
"you must specify the old server's port number.\n");
|
2012-09-04 04:15:09 +02:00
|
|
|
|
|
|
|
|
if (live_check && old_cluster.port == new_cluster.port)
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("When checking a live server, "
|
2014-05-06 18:12:18 +02:00
|
|
|
"the old and new port numbers must be different.\n");
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
2014-10-10 08:59:44 +02:00
|
|
|
* Check that locale and encoding of a database in the old and new clusters
|
|
|
|
|
* are compatible.
|
2010-05-12 04:19:11 +02:00
|
|
|
*/
|
|
|
|
|
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.
2014-10-10 08:59:44 +02:00
|
|
|
check_locale_and_encoding(DbInfo *olddb, DbInfo *newdb)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
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);
|
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
2014-01-31 01:07:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
2014-10-10 08:59:44 +02:00
|
|
|
*
|
|
|
|
|
* 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
2014-01-31 01:07:06 +01:00
|
|
|
*/
|
|
|
|
|
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.
2014-10-10 08:59:44 +02:00
|
|
|
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
2014-01-31 01:07:06 +01:00
|
|
|
{
|
2014-10-10 12:00:53 +02:00
|
|
|
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.
2014-10-10 08:59:44 +02:00
|
|
|
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
2014-01-31 01:07:06 +01:00
|
|
|
|
2014-01-31 08:03:30 +01:00
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* 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.
|
2014-01-31 08:03:30 +01:00
|
|
|
*/
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
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
2014-01-31 01:07:06 +01:00
|
|
|
|
|
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* 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
2014-01-31 01:07:06 +01:00
|
|
|
*/
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
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
2014-01-31 01:07:06 +01:00
|
|
|
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
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
2014-01-31 01:07:06 +01:00
|
|
|
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
if (lena == lenb && pg_strncasecmp(canona, canonb, lena) == 0)
|
2015-07-02 19:58:51 +02:00
|
|
|
{
|
|
|
|
|
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.
2014-10-10 08:59:44 +02:00
|
|
|
return true;
|
2015-07-02 19:58:51 +02:00
|
|
|
}
|
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
2014-01-31 01:07:06 +01:00
|
|
|
|
2015-07-02 19:58:51 +02:00
|
|
|
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.
2014-10-10 08:59:44 +02:00
|
|
|
return false;
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
2011-04-20 03:00:29 +02:00
|
|
|
check_new_cluster_is_empty(void)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
for (dbnum = 0; dbnum < new_cluster.dbarr.ndbs; dbnum++)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
|
int relnum;
|
2010-10-19 23:38:16 +02:00
|
|
|
RelInfoArr *rel_arr = &new_cluster.dbarr.dbs[dbnum].rel_arr;
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
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)
|
2018-05-18 23:17:57 +02:00
|
|
|
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);
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
}
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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];
|
2010-05-12 04:19:11 +02:00
|
|
|
|
Change the way encoding and locale checks are done in pg_upgrade.
Lc_collate and lc_ctype have been per-database settings since server version
8.4, but pg_upgrade was still treating them as cluster-wide options. It
fetched the values for the template0 databases in old and new cluster, and
compared them. That's backwards; the encoding and locale of the template0
database doesn't matter, as template0 is guaranteed to contain only ASCII
characters. But if there are any other databases that exist on both clusters
(in particular template1 and postgres databases), their encodings and
locales must be compatible.
Also, make the locale comparison more lenient. If the locale names are not
equal, try to canonicalize both of them by passing them to setlocale(). We
used to do that only when upgrading from 9.1 or below, but it seems like a
good idea even with newer versions. If we change the canonical form of a
locale, this allows pg_upgrade to still work. I'm about to do just that to
fix bug #11431, by mapping a locale name that contains non-ASCII characters
to a pure-ASCII alias of the same locale.
No backpatching, because earlier versions of pg_upgrade still support
upgrading from 8.3 servers. That would be more complicated, so it doesn't
seem worth it, given that we haven't received any complaints about this
from users.
2014-10-10 08:59:44 +02:00
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2011-04-20 03:00:29 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2012-03-16 23:54:11 +01:00
|
|
|
/*
|
|
|
|
|
* create_script_for_cluster_analyze()
|
|
|
|
|
*
|
|
|
|
|
* This incrementally generates better optimizer statistics
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
create_script_for_cluster_analyze(char **analyze_script_file_name)
|
|
|
|
|
{
|
|
|
|
|
FILE *script = NULL;
|
2016-08-08 16:07:46 +02:00
|
|
|
PQExpBufferData user_specification;
|
2013-06-29 01:11:51 +02:00
|
|
|
|
2012-03-16 23:54:11 +01:00
|
|
|
prep_status("Creating script to analyze new cluster");
|
|
|
|
|
|
2016-08-08 16:07:46 +02:00
|
|
|
initPQExpBuffer(&user_specification);
|
2013-10-13 06:09:18 +02:00
|
|
|
if (os_info.user_specified)
|
2016-08-08 16:07:46 +02:00
|
|
|
{
|
|
|
|
|
appendPQExpBufferStr(&user_specification, "-U ");
|
|
|
|
|
appendShellString(&user_specification, os_info.user);
|
|
|
|
|
appendPQExpBufferChar(&user_specification, ' ');
|
|
|
|
|
}
|
2013-10-13 06:09:18 +02:00
|
|
|
|
2014-10-12 00:38:41 +02:00
|
|
|
*analyze_script_file_name = psprintf("%sanalyze_new_cluster.%s",
|
|
|
|
|
SCRIPT_PREFIX, SCRIPT_EXT);
|
2012-03-16 23:54:11 +01:00
|
|
|
|
|
|
|
|
if ((script = fopen_priv(*analyze_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>
2016-10-01 02:40:27 +02:00
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
*analyze_script_file_name, strerror(errno));
|
2012-03-16 23:54:11 +01:00
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
|
/* add shebang header */
|
|
|
|
|
fprintf(script, "#!/bin/sh\n\n");
|
2012-09-04 11:49:22 +02:00
|
|
|
#else
|
|
|
|
|
/* suppress command echoing */
|
2012-09-04 15:39:49 +02:00
|
|
|
fprintf(script, "@echo off\n");
|
2012-03-16 23:54:11 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
fprintf(script, "echo %sThis script will generate minimal optimizer statistics rapidly%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-03-16 23:54:11 +01:00
|
|
|
fprintf(script, "echo %sso your system is usable, and then gather statistics twice more%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-03-16 23:54:11 +01:00
|
|
|
fprintf(script, "echo %swith increasing accuracy. When it is done, your system will%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-03-16 23:54:11 +01:00
|
|
|
fprintf(script, "echo %shave the default level of optimizer statistics.%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-09-04 11:49:22 +02:00
|
|
|
fprintf(script, "echo%s\n\n", ECHO_BLANK);
|
2012-03-16 23:54:11 +01:00
|
|
|
|
|
|
|
|
fprintf(script, "echo %sIf you have used ALTER TABLE to modify the statistics target for%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-03-16 23:54:11 +01:00
|
|
|
fprintf(script, "echo %sany tables, you might want to remove them and restore them after%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-03-16 23:54:11 +01:00
|
|
|
fprintf(script, "echo %srunning this script because they will delay fast statistics generation.%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-09-04 11:49:22 +02:00
|
|
|
fprintf(script, "echo%s\n\n", ECHO_BLANK);
|
2012-03-16 23:54:11 +01:00
|
|
|
|
|
|
|
|
fprintf(script, "echo %sIf you would like default statistics as quickly as possible, cancel%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-03-16 23:54:11 +01:00
|
|
|
fprintf(script, "echo %sthis script and run:%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2013-06-29 01:11:51 +02:00
|
|
|
fprintf(script, "echo %s \"%s/vacuumdb\" %s--all %s%s\n", ECHO_QUOTE,
|
2016-08-08 16:07:46 +02:00
|
|
|
new_cluster.bindir, user_specification.data,
|
2012-06-10 21:20:04 +02:00
|
|
|
/* Did we copy the free space files? */
|
|
|
|
|
(GET_MAJOR_VERSION(old_cluster.major_version) >= 804) ?
|
|
|
|
|
"--analyze-only" : "--analyze", ECHO_QUOTE);
|
2012-09-04 11:49:22 +02:00
|
|
|
fprintf(script, "echo%s\n\n", ECHO_BLANK);
|
2012-03-16 23:54:11 +01:00
|
|
|
|
2014-04-15 05:15:05 +02:00
|
|
|
fprintf(script, "\"%s/vacuumdb\" %s--all --analyze-in-stages\n",
|
2016-08-08 16:07:46 +02:00
|
|
|
new_cluster.bindir, user_specification.data);
|
2012-06-10 21:20:04 +02:00
|
|
|
/* Did we copy the free space files? */
|
2014-04-15 05:15:05 +02:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) < 804)
|
|
|
|
|
fprintf(script, "\"%s/vacuumdb\" %s--all\n", new_cluster.bindir,
|
2016-08-08 16:07:46 +02:00
|
|
|
user_specification.data);
|
2012-03-16 23:54:11 +01:00
|
|
|
|
2012-09-04 11:49:22 +02:00
|
|
|
fprintf(script, "echo%s\n\n", ECHO_BLANK);
|
2012-03-16 23:54:11 +01:00
|
|
|
fprintf(script, "echo %sDone%s\n",
|
2012-06-10 21:20:04 +02:00
|
|
|
ECHO_QUOTE, ECHO_QUOTE);
|
2012-03-16 23:54:11 +01:00
|
|
|
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
|
if (chmod(*analyze_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>
2016-10-01 02:40:27 +02:00
|
|
|
pg_fatal("could not add execute permission to file \"%s\": %s\n",
|
|
|
|
|
*analyze_script_file_name, strerror(errno));
|
2012-03-16 23:54:11 +01:00
|
|
|
#endif
|
|
|
|
|
|
2016-08-08 16:07:46 +02:00
|
|
|
termPQExpBuffer(&user_specification);
|
2013-06-29 01:11:51 +02:00
|
|
|
|
2012-03-16 23:54:11 +01:00
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
/*
|
|
|
|
|
* create_script_for_old_cluster_deletion()
|
|
|
|
|
*
|
|
|
|
|
* This is particularly useful for tablespace deletion.
|
|
|
|
|
*/
|
|
|
|
|
void
|
2011-06-22 23:50:40 +02:00
|
|
|
create_script_for_old_cluster_deletion(char **deletion_script_file_name)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
int tblnum;
|
2016-06-10 00:02:36 +02:00
|
|
|
char old_cluster_pgdata[MAXPGPATH],
|
|
|
|
|
new_cluster_pgdata[MAXPGPATH];
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2014-10-12 00:38:41 +02:00
|
|
|
*deletion_script_file_name = psprintf("%sdelete_old_cluster.%s",
|
|
|
|
|
SCRIPT_PREFIX, SCRIPT_EXT);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2016-02-19 00:32:27 +01:00
|
|
|
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,
|
2016-06-10 00:02:36 +02:00
|
|
|
"\nWARNING: new data directory should not be inside the old data directory, e.g. %s\n", old_cluster_pgdata);
|
2016-02-19 00:32:27 +01:00
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
|
2013-02-14 16:53:03 +01:00
|
|
|
/*
|
2013-05-29 22:58:43 +02:00
|
|
|
* Some users (oddly) create tablespaces inside the cluster data
|
|
|
|
|
* directory. We can't create a proper old cluster delete script in that
|
|
|
|
|
* case.
|
2013-02-14 16:53:03 +01:00
|
|
|
*/
|
|
|
|
|
for (tblnum = 0; tblnum < os_info.num_old_tablespaces; tblnum++)
|
|
|
|
|
{
|
|
|
|
|
char old_tablespace_dir[MAXPGPATH];
|
2013-05-29 22:58:43 +02:00
|
|
|
|
2013-02-14 16:53:03 +01:00
|
|
|
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))
|
|
|
|
|
{
|
2015-04-28 23:35:12 +02:00
|
|
|
/* reproduce warning from CREATE TABLESPACE that is in the log */
|
|
|
|
|
pg_log(PG_WARNING,
|
2015-05-24 03:35:49 +02:00
|
|
|
"\nWARNING: user-defined tablespace locations should not be inside the data directory, e.g. %s\n", old_tablespace_dir);
|
2015-04-28 23:35:12 +02:00
|
|
|
|
2013-02-14 16:53:03 +01:00
|
|
|
/* 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");
|
|
|
|
|
|
2012-03-13 00:47:54 +01:00
|
|
|
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>
2016-10-01 02:40:27 +02:00
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
*deletion_script_file_name, strerror(errno));
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
|
/* add shebang header */
|
|
|
|
|
fprintf(script, "#!/bin/sh\n\n");
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* delete old cluster's default tablespace */
|
2015-05-11 18:57:48 +02:00
|
|
|
fprintf(script, RMDIR_CMD " %c%s%c\n", PATH_QUOTE,
|
|
|
|
|
fix_path_separator(old_cluster.pgdata), PATH_QUOTE);
|
2010-05-12 04:19:11 +02:00
|
|
|
|
|
|
|
|
/* delete old cluster's alternate tablespaces */
|
2013-01-09 14:57:47 +01:00
|
|
|
for (tblnum = 0; tblnum < os_info.num_old_tablespaces; tblnum++)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Do the old cluster's per-database directories share a directory
|
|
|
|
|
* with a new version-specific tablespace?
|
|
|
|
|
*/
|
2010-10-19 23:38:16 +02:00
|
|
|
if (strlen(old_cluster.tablespace_suffix) == 0)
|
2010-05-12 04:19:11 +02:00
|
|
|
{
|
|
|
|
|
/* delete per-database directories */
|
|
|
|
|
int dbnum;
|
|
|
|
|
|
|
|
|
|
fprintf(script, "\n");
|
2010-10-19 17:52:43 +02:00
|
|
|
/* remove PG_VERSION? */
|
2010-10-19 23:38:16 +02:00
|
|
|
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 804)
|
2014-02-12 22:35:24 +01:00
|
|
|
fprintf(script, RM_CMD " %s%cPG_VERSION\n",
|
2013-05-29 22:58:43 +02:00
|
|
|
fix_path_separator(os_info.old_tablespaces[tblnum]),
|
2012-09-04 00:06:47 +02:00
|
|
|
PATH_SEPARATOR);
|
2010-10-19 17:52:43 +02:00
|
|
|
|
2011-11-01 18:49:03 +01:00
|
|
|
for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++)
|
2015-05-11 18:57:48 +02:00
|
|
|
fprintf(script, RMDIR_CMD " %c%s%c%d%c\n", PATH_QUOTE,
|
2013-01-09 14:57:47 +01:00
|
|
|
fix_path_separator(os_info.old_tablespaces[tblnum]),
|
2015-05-11 18:57:48 +02:00
|
|
|
PATH_SEPARATOR, old_cluster.dbarr.dbs[dbnum].db_oid,
|
|
|
|
|
PATH_QUOTE);
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
else
|
2014-02-12 22:35:24 +01:00
|
|
|
{
|
2014-05-06 18:12:18 +02:00
|
|
|
char *suffix_path = pg_strdup(old_cluster.tablespace_suffix);
|
2010-07-06 21:19:02 +02:00
|
|
|
|
2010-05-12 04:19:11 +02:00
|
|
|
/*
|
|
|
|
|
* Simply delete the tablespace directory, which might be ".old"
|
|
|
|
|
* or a version-specific subdirectory.
|
|
|
|
|
*/
|
2015-05-11 18:57:48 +02:00
|
|
|
fprintf(script, RMDIR_CMD " %c%s%s%c\n", PATH_QUOTE,
|
2013-05-29 22:58:43 +02:00
|
|
|
fix_path_separator(os_info.old_tablespaces[tblnum]),
|
2015-05-11 18:57:48 +02:00
|
|
|
fix_path_separator(suffix_path), PATH_QUOTE);
|
2014-02-12 22:35:24 +01:00
|
|
|
pfree(suffix_path);
|
|
|
|
|
}
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
2010-05-13 17:58:15 +02:00
|
|
|
#ifndef WIN32
|
2010-05-12 04:19:11 +02:00
|
|
|
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>
2016-10-01 02:40:27 +02:00
|
|
|
pg_fatal("could not add execute permission to file \"%s\": %s\n",
|
|
|
|
|
*deletion_script_file_name, strerror(errno));
|
2010-05-13 17:58:15 +02:00
|
|
|
#endif
|
2010-05-12 04:19:11 +02:00
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
check_ok();
|
2010-05-12 04:19:11 +02:00
|
|
|
}
|
2010-07-25 05:28:32 +02:00
|
|
|
|
|
|
|
|
|
2011-05-07 14:55:13 +02:00
|
|
|
/*
|
2014-08-04 17:56:16 +02:00
|
|
|
* check_is_install_user()
|
2011-05-07 14:55:13 +02:00
|
|
|
*
|
2014-08-04 17:56:16 +02:00
|
|
|
* Check we are the install user, and that the new cluster
|
|
|
|
|
* has no other users.
|
2011-05-07 14:55:13 +02:00
|
|
|
*/
|
|
|
|
|
static void
|
2014-08-04 17:56:16 +02:00
|
|
|
check_is_install_user(ClusterInfo *cluster)
|
2011-05-07 14:55:13 +02:00
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
PGconn *conn = connectToServer(cluster, "template1");
|
|
|
|
|
|
2014-08-04 17:56:16 +02:00
|
|
|
prep_status("Checking database user is the install user");
|
2011-05-09 14:55:36 +02:00
|
|
|
|
2011-05-07 14:55:13 +02:00
|
|
|
/* Can't use pg_authid because only superusers can view it. */
|
|
|
|
|
res = executeQueryOrDie(conn,
|
2012-06-13 18:19:18 +02:00
|
|
|
"SELECT rolsuper, oid "
|
2011-05-07 14:55:13 +02:00
|
|
|
"FROM pg_catalog.pg_roles "
|
2016-04-08 22:56:27 +02:00
|
|
|
"WHERE rolname = current_user "
|
|
|
|
|
"AND rolname !~ '^pg_'");
|
2011-05-07 14:55:13 +02:00
|
|
|
|
2014-08-04 17:56:16 +02:00
|
|
|
/*
|
|
|
|
|
* We only allow the install user in the new cluster (see comment below)
|
2015-05-24 03:35:49 +02:00
|
|
|
* and we preserve pg_authid.oid, so this must be the install user in the
|
|
|
|
|
* old cluster too.
|
2014-08-04 17:56:16 +02:00
|
|
|
*/
|
|
|
|
|
if (PQntuples(res) != 1 ||
|
|
|
|
|
atooid(PQgetvalue(res, 0, 1)) != BOOTSTRAP_SUPERUSERID)
|
|
|
|
|
pg_fatal("database user \"%s\" is not the install user\n",
|
2014-05-06 18:12:18 +02:00
|
|
|
os_info.user);
|
2011-05-07 14:55:13 +02:00
|
|
|
|
2012-06-13 18:19:18 +02:00
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT COUNT(*) "
|
2016-04-08 22:56:27 +02:00
|
|
|
"FROM pg_catalog.pg_roles "
|
|
|
|
|
"WHERE rolname !~ '^pg_'");
|
2012-06-13 18:19:18 +02:00
|
|
|
|
|
|
|
|
if (PQntuples(res) != 1)
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("could not determine the number of users\n");
|
2012-06-13 18:19:18 +02:00
|
|
|
|
2014-08-04 17:56:16 +02:00
|
|
|
/*
|
|
|
|
|
* 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");
|
2012-06-13 18:19:18 +02:00
|
|
|
|
2011-05-07 14:55:13 +02:00
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
2011-05-09 14:55:36 +02:00
|
|
|
|
|
|
|
|
check_ok();
|
2011-05-07 14:55:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2015-05-16 06:10:03 +02:00
|
|
|
static void
|
|
|
|
|
check_proper_datallowconn(ClusterInfo *cluster)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
PGconn *conn_template1;
|
|
|
|
|
PGresult *dbres;
|
|
|
|
|
int ntups;
|
|
|
|
|
int i_datname;
|
|
|
|
|
int i_datallowconn;
|
|
|
|
|
|
|
|
|
|
prep_status("Checking database connection settings");
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
{
|
2015-05-24 03:35:49 +02:00
|
|
|
/*
|
|
|
|
|
* avoid datallowconn == false databases from being skipped on
|
|
|
|
|
* restore
|
|
|
|
|
*/
|
2015-05-16 06:10:03 +02:00
|
|
|
if (strcmp(datallowconn, "f") == 0)
|
|
|
|
|
pg_fatal("All non-template0 databases must allow connections, "
|
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
2017-06-21 21:35:54 +02:00
|
|
|
"i.e. their pg_database.datallowconn must be true\n");
|
2015-05-16 06:10:03 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(dbres);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn_template1);
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2011-06-14 20:53:35 +02:00
|
|
|
/*
|
|
|
|
|
* 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 * "
|
2011-08-30 23:15:00 +02:00
|
|
|
"FROM pg_catalog.pg_prepared_xacts");
|
2011-06-14 20:53:35 +02:00
|
|
|
|
|
|
|
|
if (PQntuples(res) != 0)
|
2017-07-15 01:20:21 +02:00
|
|
|
{
|
|
|
|
|
if (cluster == &old_cluster)
|
|
|
|
|
pg_fatal("The source cluster contains prepared transactions\n");
|
|
|
|
|
else
|
|
|
|
|
pg_fatal("The target cluster contains prepared transactions\n");
|
|
|
|
|
}
|
2011-06-14 20:53:35 +02:00
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-07-25 05:47:29 +02:00
|
|
|
/*
|
2010-10-20 00:37:04 +02:00
|
|
|
* check_for_isn_and_int8_passing_mismatch()
|
2010-07-25 05:47:29 +02:00
|
|
|
*
|
2011-05-18 23:30:31 +02:00
|
|
|
* contrib/isn relies on data type int8, and in 8.4 int8 can now be passed
|
2010-07-25 05:47:29 +02:00
|
|
|
* by value. The schema dumps the CREATE TYPE PASSEDBYVALUE setting so
|
|
|
|
|
* it must match for the old and new servers.
|
|
|
|
|
*/
|
2011-03-07 02:14:01 +01:00
|
|
|
static void
|
2011-01-01 18:06:36 +01:00
|
|
|
check_for_isn_and_int8_passing_mismatch(ClusterInfo *cluster)
|
2010-07-25 05:47:29 +02:00
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
2011-05-18 23:30:31 +02:00
|
|
|
prep_status("Checking for contrib/isn with bigint-passing mismatch");
|
2010-07-25 05:47:29 +02:00
|
|
|
|
2010-10-19 23:38:16 +02:00
|
|
|
if (old_cluster.controldata.float8_pass_by_value ==
|
|
|
|
|
new_cluster.controldata.float8_pass_by_value)
|
2010-07-25 05:47:29 +02:00
|
|
|
{
|
|
|
|
|
/* no mismatch */
|
2010-10-19 23:38:16 +02:00
|
|
|
check_ok();
|
2010-07-25 05:47:29 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-13 00:47:54 +01:00
|
|
|
snprintf(output_path, sizeof(output_path),
|
|
|
|
|
"contrib_isn_and_int8_pass_by_value.txt");
|
2010-07-25 05:47:29 +02:00
|
|
|
|
2011-01-01 18:06:36 +01:00
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
2010-07-25 05:47:29 +02:00
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
int ntups;
|
|
|
|
|
int rowno;
|
|
|
|
|
int i_nspname,
|
|
|
|
|
i_proname;
|
2011-01-01 18:06:36 +01:00
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
2010-07-25 05:47:29 +02:00
|
|
|
|
|
|
|
|
/* Find any functions coming from contrib/isn */
|
2010-10-19 23:38:16 +02:00
|
|
|
res = executeQueryOrDie(conn,
|
2010-07-25 05:47:29 +02:00
|
|
|
"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;
|
2012-03-13 00:47:54 +01:00
|
|
|
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>
2016-10-01 02:40:27 +02:00
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
2010-07-25 05:47:29 +02:00
|
|
|
if (!db_used)
|
|
|
|
|
{
|
2019-10-09 04:16:48 +02:00
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
2010-07-25 05:47:29 +02:00
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
fprintf(script, " %s.%s\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_nspname),
|
|
|
|
|
PQgetvalue(res, rowno, i_proname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-09 03:35:42 +01:00
|
|
|
if (script)
|
2011-04-10 17:42:00 +02:00
|
|
|
fclose(script);
|
2011-03-09 03:35:42 +01:00
|
|
|
|
2010-07-25 05:47:29 +02:00
|
|
|
if (found)
|
|
|
|
|
{
|
2010-10-19 23:38:16 +02:00
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
2013-10-02 03:24:56 +02:00
|
|
|
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
2017-06-21 21:35:54 +02:00
|
|
|
"bigint data type. Your old and new clusters pass bigint values\n"
|
|
|
|
|
"differently so this cluster cannot currently be upgraded. You can\n"
|
2019-11-28 02:24:57 +01:00
|
|
|
"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"
|
2014-05-06 18:12:18 +02:00
|
|
|
" %s\n\n", output_path);
|
2010-07-25 05:47:29 +02:00
|
|
|
}
|
|
|
|
|
else
|
2010-10-19 23:38:16 +02:00
|
|
|
check_ok();
|
2010-07-25 05:47:29 +02:00
|
|
|
}
|
|
|
|
|
|
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
2020-09-18 01:38:05 +02:00
|
|
|
/*
|
|
|
|
|
* 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");
|
|
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path),
|
|
|
|
|
"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();
|
|
|
|
|
}
|
2010-07-25 05:47:29 +02:00
|
|
|
|
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
2018-11-21 00:36:57 +01:00
|
|
|
/*
|
|
|
|
|
* 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];
|
|
|
|
|
|
2019-04-29 16:05:07 +02:00
|
|
|
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
2018-11-21 00:36:57 +01:00
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path),
|
|
|
|
|
"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)
|
|
|
|
|
{
|
2019-10-09 04:16:48 +02:00
|
|
|
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
2018-11-21 00:36:57 +01:00
|
|
|
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");
|
2019-11-28 02:36:33 +01:00
|
|
|
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
2018-11-21 00:36:57 +01:00
|
|
|
" 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();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-07-25 05:28:32 +02:00
|
|
|
/*
|
|
|
|
|
* check_for_reg_data_type_usage()
|
|
|
|
|
* pg_upgrade only preserves these system values:
|
2011-12-05 22:45:19 +01:00
|
|
|
* pg_class.oid
|
2010-07-25 05:28:32 +02:00
|
|
|
* pg_type.oid
|
|
|
|
|
* pg_enum.oid
|
|
|
|
|
*
|
2011-12-05 22:45:19 +01:00
|
|
|
* Many of the reg* data types reference system catalog info that is
|
2010-07-25 05:28:32 +02:00
|
|
|
* not preserved, and hence these data types cannot be used in user
|
|
|
|
|
* tables upgraded by pg_upgrade.
|
|
|
|
|
*/
|
2011-03-07 02:14:01 +01:00
|
|
|
static void
|
2011-01-01 18:06:36 +01:00
|
|
|
check_for_reg_data_type_usage(ClusterInfo *cluster)
|
2010-07-25 05:28:32 +02:00
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
2017-08-11 21:44:10 +02:00
|
|
|
prep_status("Checking for reg* data types in user tables");
|
2010-07-25 05:28:32 +02:00
|
|
|
|
2012-03-13 00:47:54 +01:00
|
|
|
snprintf(output_path, sizeof(output_path), "tables_using_reg.txt");
|
2010-07-25 05:28:32 +02:00
|
|
|
|
2011-01-01 18:06:36 +01:00
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
2010-07-25 05:28:32 +02:00
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
int ntups;
|
|
|
|
|
int rowno;
|
|
|
|
|
int i_nspname,
|
|
|
|
|
i_relname,
|
|
|
|
|
i_attname;
|
2011-01-01 18:06:36 +01:00
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
2010-07-25 05:28:32 +02:00
|
|
|
|
2012-01-19 22:04:34 +01:00
|
|
|
/*
|
2012-06-10 21:20:04 +02:00
|
|
|
* While several relkinds don't store any data, e.g. views, they can
|
|
|
|
|
* be used to define data types of other columns, so we check all
|
|
|
|
|
* relkinds.
|
2012-01-19 22:04:34 +01:00
|
|
|
*/
|
2010-10-19 23:38:16 +02:00
|
|
|
res = executeQueryOrDie(conn,
|
2010-07-25 05:28:32 +02:00
|
|
|
"SELECT n.nspname, c.relname, a.attname "
|
|
|
|
|
"FROM pg_catalog.pg_class c, "
|
|
|
|
|
" pg_catalog.pg_namespace n, "
|
2018-11-27 08:26:05 +01:00
|
|
|
" pg_catalog.pg_attribute a, "
|
|
|
|
|
" pg_catalog.pg_type t "
|
2010-07-25 05:28:32 +02:00
|
|
|
"WHERE c.oid = a.attrelid AND "
|
|
|
|
|
" NOT a.attisdropped AND "
|
2018-11-27 08:26:05 +01:00
|
|
|
" a.atttypid = t.oid AND "
|
|
|
|
|
" t.typnamespace = "
|
|
|
|
|
" (SELECT oid FROM pg_namespace "
|
|
|
|
|
" WHERE nspname = 'pg_catalog') AND"
|
|
|
|
|
" t.typname IN ( "
|
2018-11-27 02:00:43 +01:00
|
|
|
/* regclass.oid is preserved, so 'regclass' is OK */
|
2020-03-18 21:20:01 +01:00
|
|
|
" 'regcollation', "
|
2018-11-27 08:26:05 +01:00
|
|
|
" 'regconfig', "
|
|
|
|
|
" 'regdictionary', "
|
|
|
|
|
" 'regnamespace', "
|
|
|
|
|
" 'regoper', "
|
|
|
|
|
" 'regoperator', "
|
|
|
|
|
" 'regproc', "
|
|
|
|
|
" 'regprocedure' "
|
2018-11-27 02:00:43 +01:00
|
|
|
/* regrole.oid is preserved, so 'regrole' is OK */
|
2010-10-20 00:37:04 +02:00
|
|
|
/* regtype.oid is preserved, so 'regtype' is OK */
|
2018-11-27 02:00:43 +01:00
|
|
|
" ) AND "
|
2012-06-10 21:20:04 +02:00
|
|
|
" c.relnamespace = n.oid AND "
|
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
2017-06-21 21:35:54 +02:00
|
|
|
" n.nspname NOT IN ('pg_catalog', 'information_schema')");
|
2010-07-25 05:28:32 +02:00
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
i_nspname = PQfnumber(res, "nspname");
|
|
|
|
|
i_relname = PQfnumber(res, "relname");
|
|
|
|
|
i_attname = PQfnumber(res, "attname");
|
|
|
|
|
for (rowno = 0; rowno < ntups; rowno++)
|
|
|
|
|
{
|
|
|
|
|
found = true;
|
2012-03-13 00:47:54 +01:00
|
|
|
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>
2016-10-01 02:40:27 +02:00
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
2010-07-25 05:28:32 +02:00
|
|
|
if (!db_used)
|
|
|
|
|
{
|
2019-10-09 04:16:48 +02:00
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
2010-07-25 05:28:32 +02:00
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
fprintf(script, " %s.%s.%s\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_nspname),
|
|
|
|
|
PQgetvalue(res, rowno, i_relname),
|
|
|
|
|
PQgetvalue(res, rowno, i_attname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-09 03:35:42 +01:00
|
|
|
if (script)
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
2010-07-25 05:28:32 +02:00
|
|
|
if (found)
|
|
|
|
|
{
|
2010-10-19 23:38:16 +02:00
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
2013-10-02 03:24:56 +02:00
|
|
|
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
2017-06-21 21:35:54 +02:00
|
|
|
"These data types reference system OIDs that are not preserved by\n"
|
|
|
|
|
"pg_upgrade, so this cluster cannot currently be upgraded. You can\n"
|
2019-11-28 02:36:33 +01:00
|
|
|
"remove the problem tables and restart the upgrade. A list of the\n"
|
|
|
|
|
"problem columns is in the file:\n"
|
2014-05-06 18:12:18 +02:00
|
|
|
" %s\n\n", output_path);
|
2010-07-25 05:28:32 +02:00
|
|
|
}
|
|
|
|
|
else
|
2010-10-19 23:38:16 +02:00
|
|
|
check_ok();
|
2010-07-25 05:28:32 +02:00
|
|
|
}
|
2011-06-22 23:47:23 +02:00
|
|
|
|
|
|
|
|
|
2014-09-30 02:19:59 +02:00
|
|
|
/*
|
|
|
|
|
* 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)
|
|
|
|
|
{
|
|
|
|
|
int dbnum;
|
|
|
|
|
FILE *script = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
char output_path[MAXPGPATH];
|
|
|
|
|
|
2017-09-09 23:32:10 +02:00
|
|
|
prep_status("Checking for incompatible \"jsonb\" data type");
|
2014-09-30 02:19:59 +02:00
|
|
|
|
|
|
|
|
snprintf(output_path, sizeof(output_path), "tables_using_jsonb.txt");
|
|
|
|
|
|
|
|
|
|
for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
|
|
|
|
|
{
|
|
|
|
|
PGresult *res;
|
|
|
|
|
bool db_used = false;
|
|
|
|
|
int ntups;
|
|
|
|
|
int rowno;
|
|
|
|
|
int i_nspname,
|
|
|
|
|
i_relname,
|
|
|
|
|
i_attname;
|
|
|
|
|
DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
|
|
|
|
|
PGconn *conn = connectToServer(cluster, active_db->db_name);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* While several relkinds don't store any data, e.g. views, they can
|
|
|
|
|
* be used to define data types of other columns, so we check all
|
|
|
|
|
* relkinds.
|
|
|
|
|
*/
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT n.nspname, c.relname, a.attname "
|
|
|
|
|
"FROM pg_catalog.pg_class c, "
|
|
|
|
|
" pg_catalog.pg_namespace n, "
|
|
|
|
|
" pg_catalog.pg_attribute a "
|
|
|
|
|
"WHERE c.oid = a.attrelid AND "
|
|
|
|
|
" NOT a.attisdropped AND "
|
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
2017-06-21 21:35:54 +02:00
|
|
|
" a.atttypid = 'pg_catalog.jsonb'::pg_catalog.regtype AND "
|
2014-09-30 02:19:59 +02:00
|
|
|
" c.relnamespace = n.oid AND "
|
|
|
|
|
/* exclude possible orphaned temp tables */
|
2017-08-23 02:32:17 +02:00
|
|
|
" n.nspname !~ '^pg_temp_' AND "
|
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
2017-06-21 21:35:54 +02:00
|
|
|
" n.nspname NOT IN ('pg_catalog', 'information_schema')");
|
2014-09-30 02:19:59 +02:00
|
|
|
|
|
|
|
|
ntups = PQntuples(res);
|
|
|
|
|
i_nspname = PQfnumber(res, "nspname");
|
|
|
|
|
i_relname = PQfnumber(res, "relname");
|
|
|
|
|
i_attname = PQfnumber(res, "attname");
|
|
|
|
|
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>
2016-10-01 02:40:27 +02:00
|
|
|
pg_fatal("could not open file \"%s\": %s\n",
|
|
|
|
|
output_path, strerror(errno));
|
2014-09-30 02:19:59 +02:00
|
|
|
if (!db_used)
|
|
|
|
|
{
|
2019-10-09 04:16:48 +02:00
|
|
|
fprintf(script, "In database: %s\n", active_db->db_name);
|
2014-09-30 02:19:59 +02:00
|
|
|
db_used = true;
|
|
|
|
|
}
|
|
|
|
|
fprintf(script, " %s.%s.%s\n",
|
|
|
|
|
PQgetvalue(res, rowno, i_nspname),
|
|
|
|
|
PQgetvalue(res, rowno, i_relname),
|
|
|
|
|
PQgetvalue(res, rowno, i_attname));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (script)
|
|
|
|
|
fclose(script);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
{
|
|
|
|
|
pg_log(PG_REPORT, "fatal\n");
|
2017-08-23 02:32:17 +02:00
|
|
|
pg_fatal("Your installation contains the \"jsonb\" data type in user tables.\n"
|
2019-11-28 02:36:33 +01:00
|
|
|
"The internal format of \"jsonb\" changed during 9.4 beta so this\n"
|
|
|
|
|
"cluster cannot currently be upgraded. You can remove the problem\n"
|
|
|
|
|
"tables and restart the upgrade. A list of the problem columns is\n"
|
|
|
|
|
"in the file:\n"
|
2014-09-30 02:19:59 +02:00
|
|
|
" %s\n\n", output_path);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-08 22:56:27 +02:00
|
|
|
/*
|
|
|
|
|
* 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");
|
|
|
|
|
|
2017-08-23 02:32:17 +02:00
|
|
|
prep_status("Checking for roles starting with \"pg_\"");
|
2016-04-08 22:56:27 +02:00
|
|
|
|
|
|
|
|
res = executeQueryOrDie(conn,
|
|
|
|
|
"SELECT * "
|
|
|
|
|
"FROM pg_catalog.pg_roles "
|
|
|
|
|
"WHERE rolname ~ '^pg_'");
|
|
|
|
|
|
|
|
|
|
if (PQntuples(res) != 0)
|
2017-07-15 01:20:21 +02:00
|
|
|
{
|
|
|
|
|
if (cluster == &old_cluster)
|
2017-08-23 02:32:17 +02:00
|
|
|
pg_fatal("The source cluster contains roles starting with \"pg_\"\n");
|
2017-07-15 01:20:21 +02:00
|
|
|
else
|
2017-08-23 02:32:17 +02:00
|
|
|
pg_fatal("The target cluster contains roles starting with \"pg_\"\n");
|
2017-07-15 01:20:21 +02:00
|
|
|
}
|
2016-04-08 22:56:27 +02:00
|
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
|
|
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
|
|
check_ok();
|
|
|
|
|
}
|
2014-09-30 02:19:59 +02:00
|
|
|
|
2012-10-02 17:42:34 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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;
|
|
|
|
|
|
2014-01-31 00:10:01 +01:00
|
|
|
/* get the current setting, so we can restore it. */
|
2012-10-02 17:42:34 +02:00
|
|
|
save = setlocale(category, NULL);
|
|
|
|
|
if (!save)
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("failed to get the current locale\n");
|
2012-10-02 17:42:34 +02:00
|
|
|
|
|
|
|
|
/* '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)
|
2014-01-31 00:10:01 +01:00
|
|
|
pg_fatal("failed to get system locale name for \"%s\"\n", locale);
|
2012-10-02 17:42:34 +02:00
|
|
|
|
|
|
|
|
res = pg_strdup(res);
|
|
|
|
|
|
|
|
|
|
/* restore old value. */
|
|
|
|
|
if (!setlocale(category, save))
|
2013-10-02 03:24:56 +02:00
|
|
|
pg_fatal("failed to restore old locale \"%s\"\n", save);
|
2012-10-02 17:42:34 +02:00
|
|
|
|
2012-11-25 04:12:39 +01:00
|
|
|
pg_free(save);
|
2012-10-02 17:42:34 +02:00
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|