pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedpg_upgrade --check fails to warn about abstime
9+ messages / 5 participants
[nested] [flat]
* pg_upgrade --check fails to warn about abstime
@ 2023-09-20 16:54 Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-20 17:45 ` Re: pg_upgrade --check fails to warn about abstime Tristan Partin <tristan@neon.tech>
2023-09-21 06:35 ` Re: pg_upgrade --check fails to warn about abstime Suraj Kharage <suraj.kharage@enterprisedb.com>
2023-09-22 01:46 ` Re: pg_upgrade --check fails to warn about abstime Bruce Momjian <bruce@momjian.us>
0 siblings, 3 replies; 9+ messages in thread
From: Alvaro Herrera @ 2023-09-20 16:54 UTC (permalink / raw)
To: Pg Hackers <pgsql-hackers@lists.postgresql.org>
I got a complaint that pg_upgrade --check fails to raise red flags when
the source database contains type abstime when upgrading from pg11. The
type (along with reltime and tinterval) was removed by pg12.
In passing, while testing this, I noticed that the translation
infrastructure in pg_upgrade/util.c is broken: we do have the messages
in the translation catalog, but the translations for the messages from
prep_status are never displayed. So I made the quick hack of adding _()
around the fmt, and this was the result:
Verificando Consistencia en Vivo en el Servidor Antiguo
-------------------------------------------------------
Verificando las versiones de los clústers éxito
Verificando que el usuario de base de datos es el usuario de instalaciónéxito
Verificando los parámetros de conexión de bases de datos éxito
Verificando transacciones preparadas éxito
Verificando tipos compuestos definidos por el sistema en tablas de usuarioéxito
Verificando tipos de datos reg* en datos de usuario éxito
Verificando contrib/isn con discordancia en mecanismo de paso de bigintéxito
Checking for incompatible "aclitem" data type in user tables éxito
Checking for removed "abstime" data type in user tables éxito
Checking for removed "reltime" data type in user tables éxito
Checking for removed "tinterval" data type in user tables éxito
Verificando conversiones de codificación definidas por el usuarioéxito
Verificando operadores postfix definidos por el usuario éxito
Verificando funciones polimórficas incompatibles éxito
Verificando tablas WITH OIDS éxito
Verificando columnas de usuario del tipo «sql_identifier» éxito
Verificando la presencia de las bibliotecas requeridas éxito
Verificando que el usuario de base de datos es el usuario de instalaciónéxito
Verificando transacciones preparadas éxito
Verificando los directorios de tablespaces para el nuevo clústeréxito
Note how nicely they line up ... not. There is some code that claims to
do this correctly, but apparently it counts bytes, not characters, and
also it appears to be measuring the original rather than the
translation.
I think we're trimming the strings in the wrong places. We need to
apply _() to the originals, not the trimmed ones. Anyway, clearly
nobody has looked at this very much.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"We’ve narrowed the problem down to the customer’s pants being in a situation
of vigorous combustion" (Robert Haas, Postgres expert extraordinaire)
Attachments:
[text/x-diff] 0001-pg_upgrade-check-for-types-removed-in-pg12.patch (3.5K, ../../202309201654.ng4ksea25mti@alvherre.pgsql/2-0001-pg_upgrade-check-for-types-removed-in-pg12.patch)
download | inline diff:
From 0c11fb69019e0c694249eaa70eb325a015f107f1 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Tue, 19 Sep 2023 12:30:11 +0200
Subject: [PATCH] pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
---
src/bin/pg_upgrade/check.c | 48 +++++++++++++++++++++++++++++++++++++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c
index 56e313f562..3a72c5bfd7 100644
--- a/src/bin/pg_upgrade/check.c
+++ b/src/bin/pg_upgrade/check.c
@@ -26,6 +26,8 @@ static void check_for_tables_with_oids(ClusterInfo *cluster);
static void check_for_composite_data_type_usage(ClusterInfo *cluster);
static void check_for_reg_data_type_usage(ClusterInfo *cluster);
static void check_for_aclitem_data_type_usage(ClusterInfo *cluster);
+static void check_for_removed_data_type_usage(ClusterInfo *cluster,
+ const char *datatype);
static void check_for_jsonb_9_4_usage(ClusterInfo *cluster);
static void check_for_pg_role_prefix(ClusterInfo *cluster);
static void check_for_new_tablespace_dir(void);
@@ -111,6 +113,16 @@ check_and_dump_old_cluster(bool live_check)
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1500)
check_for_aclitem_data_type_usage(&old_cluster);
+ /*
+ * PG 12 removed types abstime, reltime, tinterval.
+ */
+ if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1100)
+ {
+ check_for_removed_data_type_usage(&old_cluster, "abstime");
+ check_for_removed_data_type_usage(&old_cluster, "reltime");
+ check_for_removed_data_type_usage(&old_cluster, "tinterval");
+ }
+
/*
* PG 14 changed the function signature of encoding conversion functions.
* Conversions from older versions cannot be upgraded automatically
@@ -1215,7 +1227,8 @@ check_for_aclitem_data_type_usage(ClusterInfo *cluster)
{
char output_path[MAXPGPATH];
- prep_status("Checking for incompatible \"aclitem\" data type in user tables");
+ prep_status("Checking for incompatible \"%s\" data type in user tables",
+ "aclitem");
snprintf(output_path, sizeof(output_path), "tables_using_aclitem.txt");
@@ -1233,6 +1246,39 @@ check_for_aclitem_data_type_usage(ClusterInfo *cluster)
check_ok();
}
+/*
+ * check_for_removed_data_type_usage
+ *
+ * similar to the above, but for types that were removed in 12.
+ */
+static void
+check_for_removed_data_type_usage(ClusterInfo *cluster, const char *datatype)
+{
+ char output_path[MAXPGPATH];
+ char typename[NAMEDATALEN];
+
+ prep_status("Checking for removed \"%s\" data type in user tables",
+ datatype);
+
+ snprintf(output_path, sizeof(output_path), "tables_using_%s.txt",
+ datatype);
+ snprintf(typename, sizeof(typename), "pg_catalog.%s", datatype);
+
+ if (check_for_data_type_usage(cluster, typename, output_path))
+ {
+ pg_log(PG_REPORT, "fatal");
+ pg_fatal("Your installation contains the \"%s\" data type in user tables.\n"
+ "Data type \"%s\" has been removed in PostgreSQL version 12,\n"
+ "so this cluster cannot currently be upgraded. You can drop the\n"
+ "problem columns, or change them to another data type, and restart\n"
+ "the upgrade. A list of the problem columns is in the file:\n"
+ " %s", datatype, datatype, output_path);
+ }
+ else
+ check_ok();
+}
+
+
/*
* check_for_jsonb_9_4_usage()
*
--
2.39.2
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2023-09-20 17:45 ` Tristan Partin <tristan@neon.tech>
2023-09-20 17:58 ` Re: pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
2 siblings, 1 reply; 9+ messages in thread
From: Tristan Partin @ 2023-09-20 17:45 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
> +/*
> + * check_for_removed_data_type_usage
> + *
> + * similar to the above, but for types that were removed in 12.
> + */
> +static void
> +check_for_removed_data_type_usage(ClusterInfo *cluster, const char *datatype)
Seems like you could make this more generic instead of hardcoding
version 12, and then you could use it for any future removed types as
well.
Just a thought.
--
Tristan Partin
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-20 17:45 ` Re: pg_upgrade --check fails to warn about abstime Tristan Partin <tristan@neon.tech>
@ 2023-09-20 17:58 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-20 18:13 ` Re: pg_upgrade --check fails to warn about abstime Tristan Partin <tristan@neon.tech>
0 siblings, 1 reply; 9+ messages in thread
From: Alvaro Herrera @ 2023-09-20 17:58 UTC (permalink / raw)
To: Tristan Partin <tristan@neon.tech>; +Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
On 2023-Sep-20, Tristan Partin wrote:
> > +/*
> > + * check_for_removed_data_type_usage
> > + *
> > + * similar to the above, but for types that were removed in 12.
> > + */
> > +static void
> > +check_for_removed_data_type_usage(ClusterInfo *cluster, const char *datatype)
>
> Seems like you could make this more generic instead of hardcoding version
> 12, and then you could use it for any future removed types as well.
Yeah, I thought about that, and then closed that with "we can whack it
around when we need it". At this point I imagine there's very few other
datatypes we can remove from the core server, if any.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-20 17:45 ` Re: pg_upgrade --check fails to warn about abstime Tristan Partin <tristan@neon.tech>
2023-09-20 17:58 ` Re: pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2023-09-20 18:13 ` Tristan Partin <tristan@neon.tech>
0 siblings, 0 replies; 9+ messages in thread
From: Tristan Partin @ 2023-09-20 18:13 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
On Wed Sep 20, 2023 at 12:58 PM CDT, Alvaro Herrera wrote:
> On 2023-Sep-20, Tristan Partin wrote:
>
> > > +/*
> > > + * check_for_removed_data_type_usage
> > > + *
> > > + * similar to the above, but for types that were removed in 12.
> > > + */
> > > +static void
> > > +check_for_removed_data_type_usage(ClusterInfo *cluster, const char *datatype)
> >
> > Seems like you could make this more generic instead of hardcoding version
> > 12, and then you could use it for any future removed types as well.
>
> Yeah, I thought about that, and then closed that with "we can whack it
> around when we need it". At this point I imagine there's very few other
> datatypes we can remove from the core server, if any.
Makes complete sense to me. Patch looks good to me with one comment.
> + pg_fatal("Your installation contains the \"%s\" data type in user tables.\n"
> + "Data type \"%s\" has been removed in PostgreSQL version 12,\n"
> + "so this cluster cannot currently be upgraded. You can drop the\n"
> + "problem columns, or change them to another data type, and restart\n"
> + "the upgrade. A list of the problem columns is in the file:\n"
> + " %s", datatype, datatype, output_path);
I would wrap the second \"%s\" in commas.
> Data type, "abstime", has been...
Maybe also add a "The" to start that sentence to make it less terse. Up
to you.
--
Tristan Partin
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2023-09-21 06:35 ` Suraj Kharage <suraj.kharage@enterprisedb.com>
2 siblings, 0 replies; 9+ messages in thread
From: Suraj Kharage @ 2023-09-21 06:35 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Thanks, Alvaro, for working on this.
The patch looks good to me.
+ * similar to the above, but for types that were removed in 12.
Comment can start with a capital letter.
Also, We need to backport the same, right?
On Wed, Sep 20, 2023 at 10:24 PM Alvaro Herrera <alvherre@alvh.no-ip.org>
wrote:
> I got a complaint that pg_upgrade --check fails to raise red flags when
> the source database contains type abstime when upgrading from pg11. The
> type (along with reltime and tinterval) was removed by pg12.
>
>
> In passing, while testing this, I noticed that the translation
> infrastructure in pg_upgrade/util.c is broken: we do have the messages
> in the translation catalog, but the translations for the messages from
> prep_status are never displayed. So I made the quick hack of adding _()
> around the fmt, and this was the result:
>
> Verificando Consistencia en Vivo en el Servidor Antiguo
> -------------------------------------------------------
> Verificando las versiones de los clústers éxito
> Verificando que el usuario de base de datos es el usuario de
> instalaciónéxito
> Verificando los parámetros de conexión de bases de datos éxito
> Verificando transacciones preparadas éxito
> Verificando tipos compuestos definidos por el sistema en tablas de
> usuarioéxito
> Verificando tipos de datos reg* en datos de usuario éxito
> Verificando contrib/isn con discordancia en mecanismo de paso de
> bigintéxito
> Checking for incompatible "aclitem" data type in user tables éxito
> Checking for removed "abstime" data type in user tables éxito
> Checking for removed "reltime" data type in user tables éxito
> Checking for removed "tinterval" data type in user tables éxito
> Verificando conversiones de codificación definidas por el usuarioéxito
> Verificando operadores postfix definidos por el usuario éxito
> Verificando funciones polimórficas incompatibles éxito
> Verificando tablas WITH OIDS éxito
> Verificando columnas de usuario del tipo «sql_identifier» éxito
> Verificando la presencia de las bibliotecas requeridas éxito
> Verificando que el usuario de base de datos es el usuario de
> instalaciónéxito
> Verificando transacciones preparadas éxito
> Verificando los directorios de tablespaces para el nuevo clústeréxito
>
> Note how nicely they line up ... not. There is some code that claims to
> do this correctly, but apparently it counts bytes, not characters, and
> also it appears to be measuring the original rather than the
> translation.
>
> I think we're trimming the strings in the wrong places. We need to
> apply _() to the originals, not the trimmed ones. Anyway, clearly
> nobody has looked at this very much.
>
> --
> Álvaro Herrera PostgreSQL Developer —
> https://www.EnterpriseDB.com/
> "We’ve narrowed the problem down to the customer’s pants being in a
> situation
> of vigorous combustion" (Robert Haas, Postgres expert extraordinaire)
>
--
--
Thanks & Regards,
Suraj kharage,
edbpostgres.com
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2023-09-22 01:46 ` Bruce Momjian <bruce@momjian.us>
2023-09-22 03:18 ` Re: pg_upgrade --check fails to warn about abstime Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 9+ messages in thread
From: Bruce Momjian @ 2023-09-22 01:46 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, Sep 20, 2023 at 06:54:24PM +0200, Álvaro Herrera wrote:
> I got a complaint that pg_upgrade --check fails to raise red flags when
> the source database contains type abstime when upgrading from pg11. The
> type (along with reltime and tinterval) was removed by pg12.
Wow, I never added code to pg_upgrade to check for that, and no one
complained either.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-22 01:46 ` Re: pg_upgrade --check fails to warn about abstime Bruce Momjian <bruce@momjian.us>
@ 2023-09-22 03:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-22 11:14 ` Re: pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 9+ messages in thread
From: Tom Lane @ 2023-09-22 03:18 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Sep 20, 2023 at 06:54:24PM +0200, Álvaro Herrera wrote:
>> I got a complaint that pg_upgrade --check fails to raise red flags when
>> the source database contains type abstime when upgrading from pg11. The
>> type (along with reltime and tinterval) was removed by pg12.
> Wow, I never added code to pg_upgrade to check for that, and no one
> complained either.
Yeah, so most people had indeed listened to warnings and moved away
from those datatypes. I'm inclined to think that adding code for this
at this point is a bit of a waste of time.
regards, tom lane
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-22 01:46 ` Re: pg_upgrade --check fails to warn about abstime Bruce Momjian <bruce@momjian.us>
2023-09-22 03:18 ` Re: pg_upgrade --check fails to warn about abstime Tom Lane <tgl@sss.pgh.pa.us>
@ 2023-09-22 11:14 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-27 05:40 ` Re: pg_upgrade --check fails to warn about abstime Suraj Kharage <suraj.kharage@enterprisedb.com>
0 siblings, 1 reply; 9+ messages in thread
From: Alvaro Herrera @ 2023-09-22 11:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <bruce@momjian.us>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
On 2023-Sep-21, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Wow, I never added code to pg_upgrade to check for that, and no one
> > complained either.
>
> Yeah, so most people had indeed listened to warnings and moved away
> from those datatypes. I'm inclined to think that adding code for this
> at this point is a bit of a waste of time.
The migrations from versions prior to 12 have not stopped yet, and I did
receive a complaint about it. Because the change is so simple, I'm
inclined to patch it anyway, late though it is.
I decided to follow Tristan's advice to add the version number as a
parameter to the new function; this way, the knowledge of where was what
dropped is all in the callsite and none in the function. It
looked a bit schizoid otherwise.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
Attachments:
[text/x-diff] v2-0001-pg_upgrade-check-for-types-removed-in-pg12.patch (3.6K, ../../202309221114.elojolugmsmv@alvherre.pgsql/2-v2-0001-pg_upgrade-check-for-types-removed-in-pg12.patch)
download | inline diff:
From 5258379693db55618c6451ce8df4971521eb8e66 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Tue, 19 Sep 2023 12:30:11 +0200
Subject: [PATCH v2] pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
---
src/bin/pg_upgrade/check.c | 51 +++++++++++++++++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c
index 56e313f562..21a0ff9e42 100644
--- a/src/bin/pg_upgrade/check.c
+++ b/src/bin/pg_upgrade/check.c
@@ -26,6 +26,9 @@ static void check_for_tables_with_oids(ClusterInfo *cluster);
static void check_for_composite_data_type_usage(ClusterInfo *cluster);
static void check_for_reg_data_type_usage(ClusterInfo *cluster);
static void check_for_aclitem_data_type_usage(ClusterInfo *cluster);
+static void check_for_removed_data_type_usage(ClusterInfo *cluster,
+ const char *version,
+ const char *datatype);
static void check_for_jsonb_9_4_usage(ClusterInfo *cluster);
static void check_for_pg_role_prefix(ClusterInfo *cluster);
static void check_for_new_tablespace_dir(void);
@@ -111,6 +114,16 @@ check_and_dump_old_cluster(bool live_check)
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1500)
check_for_aclitem_data_type_usage(&old_cluster);
+ /*
+ * PG 12 removed types abstime, reltime, tinterval.
+ */
+ if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1100)
+ {
+ check_for_removed_data_type_usage(&old_cluster, "12", "abstime");
+ check_for_removed_data_type_usage(&old_cluster, "12", "reltime");
+ check_for_removed_data_type_usage(&old_cluster, "12", "tinterval");
+ }
+
/*
* PG 14 changed the function signature of encoding conversion functions.
* Conversions from older versions cannot be upgraded automatically
@@ -1215,7 +1228,8 @@ check_for_aclitem_data_type_usage(ClusterInfo *cluster)
{
char output_path[MAXPGPATH];
- prep_status("Checking for incompatible \"aclitem\" data type in user tables");
+ prep_status("Checking for incompatible \"%s\" data type in user tables",
+ "aclitem");
snprintf(output_path, sizeof(output_path), "tables_using_aclitem.txt");
@@ -1233,6 +1247,41 @@ check_for_aclitem_data_type_usage(ClusterInfo *cluster)
check_ok();
}
+/*
+ * check_for_removed_data_type_usage
+ *
+ * Check for in-core data types that have been removed. Callers know
+ * the exact list.
+ */
+static void
+check_for_removed_data_type_usage(ClusterInfo *cluster, const char *version,
+ const char *datatype)
+{
+ char output_path[MAXPGPATH];
+ char typename[NAMEDATALEN];
+
+ prep_status("Checking for removed \"%s\" data type in user tables",
+ datatype);
+
+ snprintf(output_path, sizeof(output_path), "tables_using_%s.txt",
+ datatype);
+ snprintf(typename, sizeof(typename), "pg_catalog.%s", datatype);
+
+ if (check_for_data_type_usage(cluster, typename, output_path))
+ {
+ pg_log(PG_REPORT, "fatal");
+ pg_fatal("Your installation contains the \"%s\" data type in user tables.\n"
+ "The \"%s\" type has been removed in PostgreSQL version %s,\n"
+ "so this cluster cannot currently be upgraded. You can drop the\n"
+ "problem columns, or change them to another data type, and restart\n"
+ "the upgrade. A list of the problem columns is in the file:\n"
+ " %s", datatype, datatype, version, output_path);
+ }
+ else
+ check_ok();
+}
+
+
/*
* check_for_jsonb_9_4_usage()
*
--
2.39.2
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: pg_upgrade --check fails to warn about abstime
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-22 01:46 ` Re: pg_upgrade --check fails to warn about abstime Bruce Momjian <bruce@momjian.us>
2023-09-22 03:18 ` Re: pg_upgrade --check fails to warn about abstime Tom Lane <tgl@sss.pgh.pa.us>
2023-09-22 11:14 ` Re: pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2023-09-27 05:40 ` Suraj Kharage <suraj.kharage@enterprisedb.com>
0 siblings, 0 replies; 9+ messages in thread
From: Suraj Kharage @ 2023-09-27 05:40 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; Pg Hackers <pgsql-hackers@lists.postgresql.org>
On Fri, Sep 22, 2023 at 4:44 PM Alvaro Herrera <alvherre@alvh.no-ip.org>
wrote:
> On 2023-Sep-21, Tom Lane wrote:
>
> > Bruce Momjian <bruce@momjian.us> writes:
>
> > > Wow, I never added code to pg_upgrade to check for that, and no one
> > > complained either.
> >
> > Yeah, so most people had indeed listened to warnings and moved away
> > from those datatypes. I'm inclined to think that adding code for this
> > at this point is a bit of a waste of time.
>
> The migrations from versions prior to 12 have not stopped yet, and I did
> receive a complaint about it. Because the change is so simple, I'm
> inclined to patch it anyway, late though it is.
>
> I decided to follow Tristan's advice to add the version number as a
> parameter to the new function; this way, the knowledge of where was what
> dropped is all in the callsite and none in the function. It
> looked a bit schizoid otherwise.
>
yeah, looks good to me.
>
> --
> Álvaro Herrera 48°01'N 7°57'E —
> https://www.EnterpriseDB.com/
> "Postgres is bloatware by design: it was built to house
> PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
>
--
--
Thanks & Regards,
Suraj kharage,
edbpostgres.com
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2023-09-27 05:40 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-09-20 16:54 pg_upgrade --check fails to warn about abstime Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-20 17:45 ` Tristan Partin <tristan@neon.tech>
2023-09-20 17:58 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-20 18:13 ` Tristan Partin <tristan@neon.tech>
2023-09-21 06:35 ` Suraj Kharage <suraj.kharage@enterprisedb.com>
2023-09-22 01:46 ` Bruce Momjian <bruce@momjian.us>
2023-09-22 03:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-22 11:14 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2023-09-27 05:40 ` Suraj Kharage <suraj.kharage@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox