Re: Do we still need MULE_INTERNAL? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Do we still need MULE_INTERNAL?
Date
Msg-id CA+hUKGJjnWaXfkkrgSLxWqxbb16x7W3PbKOvpL70yv9hNP=vVg@mail.gmail.com
Whole thread
In response to Re: Do we still need MULE_INTERNAL?  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: Do we still need MULE_INTERNAL?
List pgsql-hackers
Thanks for both of those reviews!  I'll push this shortly, with that
stray mention removed from the documentation.

Here's what I came up with for pg_upgrade.  It tests each database's
encodings with PG_VALID_BE_ENCODING(), and looks like this when it
fails:

Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok
Checking database connection settings                         ok
Checking for unsupported encodings                            fatal

Your installation contains databases using encodings that are
no longer supported.  Consider dumping and restoring with UTF8.
A list of databases with unsupported encodings is in the file:
    pgdata_new/pg_upgrade_output.d/20260408T170229.964/databases_unsupported_encoding.txt
Failure, exiting

$ cat pgdata_new/pg_upgrade_output.d/20260408T170229.964/databases_unsupported_encoding.txt
postgres
template1
template0

I'll wait a bit longer for this one, on the off chance of reviews at
this late hour.

Attachment

pgsql-hackers by date:

Previous
From: Siddharth Kothari
Date:
Subject: Re: [PATCH] Add RetrieveInstrumentation hook for CustomScan providers
Next
From: Amit Kapila
Date:
Subject: Re: [Proposal] Adding Log File Capability to pg_createsubscriber