Re: pg_upgrade --check fails to warn about abstime

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,

edbpostgres.com

In response to

Browse pgsql-hackers by date

  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