Re: Do we still need MULE_INTERNAL?

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: pgsql(at)j-davis(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: Do we still need MULE_INTERNAL?
Date: 2026-04-08 05:29:26
Message-ID: CA+hUKGJjnWaXfkkrgSLxWqxbb16x7W3PbKOvpL70yv9hNP=vVg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
0001-pg_upgrade-Check-for-unsupported-encodings.patch text/x-patch 3.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-04-08 05:30:58 Re: [Proposal] Adding Log File Capability to pg_createsubscriber
Previous Message Siddharth Kothari 2026-04-08 05:27:16 Re: [PATCH] Add RetrieveInstrumentation hook for CustomScan providers