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

From Jeff Davis
Subject Re: Do we still need MULE_INTERNAL?
Date
Msg-id 790a2e194c2d8cb03a2f1b8b580b64f25a5095b0.camel@j-davis.com
Whole thread Raw
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
On Wed, 2026-04-01 at 08:38 +0900, Tatsuo Ishii wrote:
> In my case pg_upgrade does not fail.
>
> Old clsuter:
> - create pg18 cluster with SQL_ASCII encoding
> - create MULE_INTERNAL encoding database
> - drop the MULE_INTERNAL database
>
> New cluster:
> - create pg19dev cluster with SQL_ASCII encoding
>
> Run pg_upgrade

Repro of my case:

  cd pgsql18dbg
  ./bin/initdb -D data -N -E MULE_INTERNAL --locale=C
  ./bin/pg_ctl -D data -l logfile start
  PGCLIENTENCODING=SQL_ASCII ./bin/psql postgres \
    -c 'create table x(t text);'
  ./bin/pg_ctl -D data stop
  cd ../pgsql19dbg
  ./bin/initdb -D data -N -E SQL_ASCII --locale=C
  ./bin/pg_upgrade -b ../pgsql18dbg/bin -B bin \
    -d ../pgsql18dbg/data -D data

  ===========================
  ...
  Performing Upgrade
  ------------------
  ...
  Setting frozenxid and minmxid counters in new cluster
connection to server on socket ".../pgsql19dbg/.s.PGSQL.50432" failed:
FATAL:  invalid database encoding: 7

  Failure, exiting
  ===========================

It's easy to fix by just rejecting MULE_INTERNAL during the "check"
phase.

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: vectorized CRC on ARM64
Next
From: Andreas Karlsson
Date:
Subject: Minor cleanup of Meson files given that we require 0.57