From: | Suraj Kharage <suraj(dot)kharage(at)enterprisedb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade --check fails to warn about abstime |
Date: | 2023-09-21 06:35:43 |
Message-ID: | CAF1DzPWpersEhyW+A+QXdmL7MiqCMm1RYgDxdTvj_CAdT-8VUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)alvh(dot)no-ip(dot)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,
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-09-21 06:56:29 | Re: Bug fix in vacuumdb --buffer-usage-limit xxx -Z |
Previous Message | Noah Misch | 2023-09-21 06:22:10 | Re: Unlogged relation copy is not fsync'd |