Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vLApF-006fAt-0C for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Nov 2025 01:48:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vLApB-0037Cw-26 for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Nov 2025 01:48:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vLApB-0037Co-0Z for pgsql-hackers@lists.postgresql.org; Tue, 18 Nov 2025 01:48:05 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vLAp9-0005mB-1v for pgsql-hackers@lists.postgresql.org; Tue, 18 Nov 2025 01:48:05 +0000 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-64312565c10so7433903a12.2 for ; Mon, 17 Nov 2025 17:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763430482; x=1764035282; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RTBIY9uytbqjXnRyFh+yUnhgnBJI3b9Co67SI70PUyI=; b=gJsX0+9MkihDOXhfEu5AYELbXmdb044S8JtYcQ6qxjyFR8FdvSRDRtTwPm/WjD2NDD BDg5Sube3KXNOSQlf1ldMZ4u5EllI4k8/pp03uGNMlagGzzfldZlmr1Dh9bypWKEQQkn shHNukl91CBTAa1EpN10BbH+NWoaqpCMKTHuWIdiVLXNf4S2HODZ9sI+c9qzIMp3B2Go jPLsF/aidk7TrqsSMR6LmIZBf/vqHOwrbufYSR10YhS5g4VmYaQlQKuhrjTFwQW6PzcV d4Rz4MeOzVsj9uTrd16AxXWZAvQTAqHAeMM45X3QwzQugxMJ0LBNyYtH9o2fR8fZggc0 P38Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763430482; x=1764035282; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RTBIY9uytbqjXnRyFh+yUnhgnBJI3b9Co67SI70PUyI=; b=UXXwHP7jwYdFtGgT7Xy8mO9EcyGIfvJ3K8toiK7/vqouw7WKDLZJvTqoY8XDhE7HEQ 5S4o2rjolxaDePV2qUCvcAttrLkZ9RfYNYTpM+1/Le6hjttollQpLfIlnPVThTf022Xp 5GfIl8/ThYQimIyjaiqh44Zb0qn65Vd++GSh63CSPI4XtbZFyvwmCeJWPVTeLcR6WMQg B73LV1QCD1IFOZ/Ctxakulg2DEkWpzYXTYZMkcefzc0J9o+LnPvuvHm7YnPHmhpMkWA2 Sf52vB1As1xphSYmc2h+Jdk5UsqNJHz4HVYd483i5wGZgjkDLMhDeuDjgjouihc/9hH4 sJdw== X-Forwarded-Encrypted: i=1; AJvYcCXn1Qbv7PVoRYYy1sQ8u1R87Ihr5kQcntTil9eARo7fBQsuNAd/Tdhqlux+q9amGMNUOh4o7tXsmqHPxz2L@lists.postgresql.org X-Gm-Message-State: AOJu0Yz9tqr7kLkJDkcNfNB2fUfIOCAgUwOZwTk+PwNzs1a+maaar1gG bZrcsJ/BxlkijT6YXSvKi6MFSTt14m3ybftjQQXbF5uEAJXMaS46aeiyU8N6FiFzG2sbpJbq6kX WVoeReTa9ZIKDN4X4Ryocgmt7hVDU4Ns= X-Gm-Gg: ASbGncso+97QaqhGvEZpqSPImPypQKWR3shemYA1rfIQcvcceqd+49dgh11sVh75Rdu wGvXTrMgWmMG4V3qz7q8tB1XZW5v8niCnM/AGNJk0fQCswvAITkzGF3KHlRlSTmDUuCtE983ZSr h4qULtthpdZ6f/DcIY3CRmlU1dNratqU4XkblNhdAPKg1gIplaGEEIDiCPGBNsAtdQfTDRk11Py rU9lb1Cg9e5iyl22/+Dd07t26APE5K0EBrbJq5AnhcRmxPJo8n8vjNCy1HqAWe2sG6PD1rezpLY 7lHL X-Google-Smtp-Source: AGHT+IGITZKgjQFl5fIZYpQLuIMUifl7212EFSrp695bJUWfStK6t8vdmQCVP6PfZUo0kLdUst2/wiOFRlCTek+vQ5k= X-Received: by 2002:a05:6402:1d50:b0:640:7f9c:e90c with SMTP id 4fb4d7f45d1cf-64350ea7e48mr13278413a12.27.1763430481896; Mon, 17 Nov 2025 17:48:01 -0800 (PST) MIME-Version: 1.0 References: <4535f3aa-3220-4760-b1f5-2bc91f248e03@iki.fi> <2bc58592-9d74-4af0-bdd1-1a88e8683f7c@iki.fi> <36531c0e-292c-409d-bbc7-a252cf6e910a@iki.fi> <54aa8f65-f0e4-4464-b543-e0399c1cab1e@iki.fi> <4a9dda70-0af7-41a4-9636-b168f2fc48ef@iki.fi> <46cc45e9-fddd-44bc-bcb3-96889aafd921@iki.fi> In-Reply-To: <46cc45e9-fddd-44bc-bcb3-96889aafd921@iki.fi> From: wenhui qiu Date: Tue, 18 Nov 2025 09:47:45 +0800 X-Gm-Features: AWmQ_bkgtg8EnUnnfNf5o4WSUi_AtxuVkoC5jAWZqc05k-SbOso7eFPhv7o7cM8 Message-ID: Subject: Re: POC: make mxidoff 64 bits To: Heikki Linnakangas Cc: Maxim Orlov , Ashutosh Bapat , Alvaro Herrera , Alexander Korotkov , Postgres hackers Content-Type: multipart/alternative; boundary="00000000000075a66e0643d4a794" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000075a66e0643d4a794 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Heikki > I don't think we need to support that case. I hope there are no clusters > in that state still in the wild, and you can work around it by upgrading > to 9.3.5 or above and letting autovacuum run. But I wonder if a > pre-upgrade check with a better error message would still be worthwhile. I think we believe it is now highly unlikely to find instances of version 9.3; all users are advised to upgrade to the latest version first. Thanks On Tue, Nov 18, 2025 at 12:35=E2=80=AFAM Heikki Linnakangas wrote: > Here's yet another patch version. I spent the day reviewing this in > detail and doing little cleanups here and there. I squashed the commits > and wrote a proper commit message. > > One noteworthy refactoring is in pg_upgrade.c, to make it more clear (to > me at least) how upgrade from version 9.2 and below now works. It was > actually broken when I tested it. Not sure if I had broken it earlier or > if it never worked, but in any case it works now. > > I also tested upgrading a cluster from an old minor version, < 9.3.5, > where the control file has a bogus oldestMultiXid=3D=3D1 value (see commi= t > b6a3444fa6). As expected, you get a "could not open file" error: > > > Performing Upgrade > > ------------------ > > Setting locale and encoding for new cluster ok > > ... > > Deleting files from new pg_multixact/members ok > > Deleting files from new pg_multixact/offsets ok > > Converting pg_multixact files > > could not open file > "/home/heikki/pgsql.93stable/data/pg_multixact/offsets/0000": No such fil= e > or directory > > Failure, exiting > > I don't think we need to support that case. I hope there are no clusters > in that state still in the wild, and you can work around it by upgrading > to 9.3.5 or above and letting autovacuum run. But I wonder if a > pre-upgrade check with a better error message would still be worthwhile. > > > Ashutosh, you were interested in reviewing this earlier. Would you have > a chance to review this now, before I commit it? Alexander, Alvaro, > would you have a chance to take a final look too, please? > > - Heikki > --00000000000075a66e0643d4a794 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Heikki
> I don't think we need to support th= at case. I hope there are no clusters=C2=A0
> in that state still in the wild, and you can wo= rk around it by upgrading=C2=A0=
> to 9.3.5 or above and letting autovacuum run. But I wonder = if a=C2=A0
> pre-u= pgrade check with a better error message would still be worthwhile.
I think we believe it is now highly unlikely to find instances of ve= rsion 9.3; all users are advised to upgrade to the latest version first.




Thanks<= /div>

On Tue, Nov 18, 2025 at 12:35=E2=80=AFAM Heikki = Linnakangas <hlinnaka@iki.fi> = wrote:
Here's yet another patch version. I sp= ent the day reviewing this in
detail and doing little cleanups here and there. I squashed the commits and wrote a proper commit message.

One noteworthy refactoring is in pg_upgrade.c, to make it more clear (to me at least) how upgrade from version 9.2 and below now works. It was
actually broken when I tested it. Not sure if I had broken it earlier or if it never worked, but in any case it works now.

I also tested upgrading a cluster from an old minor version, < 9.3.5, where the control file has a bogus oldestMultiXid=3D=3D1 value (see commit =
b6a3444fa6). As expected, you get a "could not open file" error:<= br>
> Performing Upgrade
> ------------------
> Setting locale and encoding for new cluster=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ok
> ...
> Deleting files from new pg_multixact/members=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ok
> Deleting files from new pg_multixact/offsets=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ok
> Converting pg_multixact files=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
> could not open file "/home/heikki/pgsql.93stable/data/pg_multixac= t/offsets/0000": No such file or directory
> Failure, exiting

I don't think we need to support that case. I hope there are no cluster= s
in that state still in the wild, and you can work around it by upgrading to 9.3.5 or above and letting autovacuum run. But I wonder if a
pre-upgrade check with a better error message would still be worthwhile.

Ashutosh, you were interested in reviewing this earlier. Would you have a chance to review this now, before I commit it? Alexander, Alvaro,
would you have a chance to take a final look too, please?

- Heikki
--00000000000075a66e0643d4a794--