Horton
Menu

Re: Do we still need MULE_INTERNAL?

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: pgsql@j-davis.com, pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Date: 2026-04-08T05:29:26Z
Lists: pgsql-hackers

Attachments

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.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_upgrade: Check for unsupported encodings.

  2. Remove MULE_INTERNAL encoding.