Content-Type: multipart/mixed; boundary="------------e3n9VcYGTb2KIaENa92noGrv"
Message-ID: <24b3deb6-a732-4256-847a-560f4bf39d59@iki.fi>
Date: Tue, 12 Nov 2024 01:31:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC: make mxidoff 64 bits
To: Maxim Orlov <orlovmg@gmail.com>, wenhui qiu <qiuwenhuifx@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
 <ff143b24-a093-40da-9833-d36b83726bdf@iki.fi>
 <CAGjGUAKO1GCzG5wBMt5RosWo0PatgFpYY=Gjgt77tN2brNe=Bg@mail.gmail.com>
 <CACG=ezYokoiumOFnqUfg_ffHD5s8T+6iHYfzKLfa=QQ-1pNrBg@mail.gmail.com>
 <CACG=ezY9xq73jcX_EjVqx5-f90nbQ9PyhFCTW2fwFCS2wmNiFw@mail.gmail.com>
 <CACG=eza+27CfLBobJJccRhXrA3He6c1irAnoyTtSC1-z9UXLrg@mail.gmail.com>
 <CAPpHfduczcop9s6gKUpLGgFUe2y4ERGMJx6SS6Kp+s-kQPwMjg@mail.gmail.com>
 <CACG=ezbye4g_ERNqE=gBcvQ0YypRaVENhNUu8xrs4PL12UdnUA@mail.gmail.com>
 <CACG=ezaMncd0-BcGHBgsSR2eqHfrz9WznHGLKX8biz6zu-azGw@mail.gmail.com>
 <5ecc35f5-1111-47fc-8a02-36d89490a50d@iki.fi>
 <CACG=ezb9XTvd3ZmS0y8gUunx_wBBdJO7ou+BfCOnnA5jE-11vg@mail.gmail.com>
 <CACG=ezYFNqGjsxF6Vb2CHF6JzKcjhAFauaFm9js0nu_3Ngcdkw@mail.gmail.com>
 <CAGjGUA+dcV7veaCV1H65vCNsbS++nT8=ho772gDvsXUW9H7eXQ@mail.gmail.com>
 <CACG=ezYThNkf8QsDA-aQfEFEkqn2L=_uUL83z0vJstPRasbZqg@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <CACG=ezYThNkf8QsDA-aQfEFEkqn2L=_uUL83z0vJstPRasbZqg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/24b3deb6-a732-4256-847a-560f4bf39d59%40iki.fi>
Precedence: bulk

This is a multi-part message in MIME format.
--------------e3n9VcYGTb2KIaENa92noGrv
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08/11/2024 20:10, Maxim Orlov wrote:
> Sorry for a late reply. There was a problem in upgrade with offset 
> wraparound. Here is a fixed version. Test also added. I decide to use my 
> old patch to set a non-standard multixacts for the old cluster, fill it 
> with data and do pg_upgrade.

The wraparound logic is still not correct. To test, I created a cluster 
where multixids have wrapped around, so that:

$ ls -l data-old/pg_multixact/offsets/
total 720
-rw------- 1 heikki heikki 212992 Nov 12 01:11 0000
-rw-r--r-- 1 heikki heikki 262144 Nov 12 00:55 FFFE
-rw------- 1 heikki heikki 262144 Nov 12 00:56 FFFF

After running pg_upgrade:

$ ls -l data-new/pg_multixact/offsets/
total 1184
-rw------- 1 heikki heikki 155648 Nov 12 01:12 0001
-rw------- 1 heikki heikki 262144 Nov 12 01:11 1FFFD
-rw------- 1 heikki heikki 262144 Nov 12 01:11 1FFFE
-rw------- 1 heikki heikki 262144 Nov 12 01:11 1FFFF
-rw------- 1 heikki heikki 262144 Nov 12 01:11 20000
-rw------- 1 heikki heikki 155648 Nov 12 01:11 20001

That's not right. The segments 20000 and 20001 were created by the new 
pg_upgrade conversion code from old segment '0000'. But multixids are 
still 32-bit values, so after segment 1FFFF, you should still wrap 
around to 0000. The new segments should be '0000' and '0001'. The 
segment '0001' is created when postgres is started after upgrade, but 
it's created from scratch and doesn't contain the upgraded values.

When I try to select from a table after upgrade that contains 
post-wraparound multixids:

TRAP: failed Assert("offset != 0"), File: 
"../src/backend/access/transam/multixact.c", Line: 1353, PID: 63386


On a different note, I'm surprised you're rewriting member segments from 
scratch, parsing all the individual member groups and writing them out 
again. There's no change to the members file format, except for the 
numbering of the files, so you could just copy the files under the new 
names without paying attention to the contents. It's not wrong to parse 
them in detail, but I'd assume that it would be simpler not to.

> Here is how to test. All the patches are for 14e87ffa5c543b5f3 master 
> branch.
> 1) Get the 14e87ffa5c543b5f3 master branch apply patches 0001-Add- 
> initdb-option-to-initialize-cluster-with-non-sta.patch and 0002-TEST- 
> lower-SLRU_PAGES_PER_SEGMENT.patch
> 2) Get the 14e87ffa5c543b5f3 master branch in a separate directory and 
> apply v6 patch set.
> 3) Build two branches.
> 4) Use ENV oldinstall to run the test: PROVE_TESTS=t/005_mxidoff.pl 
> <http://005_mxidoff.pl> oldinstall=/home/orlov/proj/pgsql-new 
> PG_TEST_NOCLEAN=1 make check -C src/bin/pg_upgrade/
> 
> Maybe, I'll make a shell script to automate this steps if required.

Yeah, I think we need something to automate this. I did the testing 
manually. I used the attached python script to consume multixids faster, 
but it's still tedious.

I used pg_resetwal to quickly create a cluster that's close to multixid 
wrapround:

initdb -D data
pg_resetwal -D data -m 4294900001,4294900000
dd if=/dev/zero of=data/pg_multixact/offsets/FFFE bs=8192 count=32

-- 
Heikki Linnakangas
Neon (https://neon.tech)

--------------e3n9VcYGTb2KIaENa92noGrv
Content-Type: text/x-python; charset=UTF-8; name="multixids.py"
Content-Disposition: attachment; filename="multixids.py"
Content-Transfer-Encoding: base64

aW1wb3J0IHN5czsKaW1wb3J0IHRocmVhZGluZzsKaW1wb3J0IHBzeWNvcGcyOwoKZGVmIHRl
c3RfbXVsdGl4YWN0KHRibG5hbWU6IHN0cik6CiAgICB3aXRoIHBzeWNvcGcyLmNvbm5lY3Qo
KSBhcyBjb25uOgogICAgICAgIGN1ciA9IGNvbm4uY3Vyc29yKCkKICAgICAgICBjdXIuZXhl
Y3V0ZSgKICAgICAgICAgICAgZiIiIgogICAgICAgICAgICBEUk9QIFRBQkxFIElGIEVYSVNU
UyB7dGJsbmFtZX07CiAgICAgICAgICAgIENSRUFURSBUQUJMRSB7dGJsbmFtZX0oaSBpbnQg
cHJpbWFyeSBrZXksIG5fdXBkYXRlZCBpbnQpIFdJVEggKGF1dG92YWN1dW1fZW5hYmxlZD1m
YWxzZSk7CiAgICAgICAgICAgIElOU0VSVCBJTlRPIHt0YmxuYW1lfSBzZWxlY3QgZywgMCBm
cm9tIGdlbmVyYXRlX3NlcmllcygxLCA1MCkgZzsKICAgICAgICAgICAgIiIiCiAgICAgICAg
KQoKICAgICMgTG9jayBlbnRyaWVzIHVzaW5nIHBhcmFsbGVsIGNvbm5lY3Rpb25zIGluIGEg
cm91bmQtcm9iaW4gZmFzaGlvbi4KICAgIG5jbGllbnRzID0gNTAKICAgIHVwZGF0ZV9ldmVy
eSA9IDk3CiAgICBjb25uZWN0aW9ucyA9IFtdCiAgICBmb3IgXyBpbiByYW5nZShuY2xpZW50
cyk6CiAgICAgICAgIyBEbyBub3QgdHVybiBvbiBhdXRvY29tbWl0LiBXZSB3YW50IHRvIGhv
bGQgdGhlIGtleS1zaGFyZSBsb2Nrcy4KICAgICAgICBjb25uID0gcHN5Y29wZzIuY29ubmVj
dCgpCiAgICAgICAgY29ubmVjdGlvbnMuYXBwZW5kKGNvbm4pCgogICAgIyBPbiBlYWNoIGl0
ZXJhdGlvbiwgd2UgY29tbWl0IHRoZSBwcmV2aW91cyB0cmFuc2FjdGlvbiBvbiBhIGNvbm5l
Y3Rpb24sCiAgICAjIGFuZCBpc3N1ZSBhbm90aGVyIHNlbGVjdC4gRWFjaCBTRUxFQ1QgZ2Vu
ZXJhdGVzIGEgbmV3IG11bHRpeGFjdCB0aGF0CiAgICAjIGluY2x1ZGVzIHRoZSBuZXcgWElE
LCBhbmQgdGhlIFhJRHMgb2YgYWxsIHRoZSBvdGhlciBwYXJhbGxlbCB0cmFuc2FjdGlvbnMu
CiAgICAjIFRoaXMgZ2VuZXJhdGVzIGVub3VnaCB0cmFmZmljIG9uIGJvdGggbXVsdGl4YWN0
IG9mZnNldHMgYW5kIG1lbWJlcnMgU0xSVXMKICAgICMgdG8gY3Jvc3MgcGFnZSBib3VuZGFy
aWVzLgogICAgZm9yIGkgaW4gcmFuZ2UoMjAwMDApOgogICAgICAgIGNvbm4gPSBjb25uZWN0
aW9uc1tpICUgbmNsaWVudHNdCiAgICAgICAgY29ubi5jb21taXQoKQoKICAgICAgICAjIFBl
cmZvcm0gc29tZSBub24ta2V5IFVQREFURXMgdG9vLCB0byBleGVyY2lzZSBkaWZmZXJlbnQg
bXVsdGl4YWN0CiAgICAgICAgIyBtZW1iZXIgc3RhdHVzZXMuCiAgICAgICAgaWYgaSAlIHVw
ZGF0ZV9ldmVyeSA9PSAwOgogICAgICAgICAgICBjb25uLmN1cnNvcigpLmV4ZWN1dGUoZiJ1
cGRhdGUge3RibG5hbWV9IHNldCBuX3VwZGF0ZWQgPSBuX3VwZGF0ZWQgKyAxIHdoZXJlIGkg
PSB7aSAlIDUwfSIpCiAgICAgICAgZWxzZToKICAgICAgICAgICAgY29ubi5jdXJzb3IoKS5l
eGVjdXRlKGYic2VsZWN0ICogZnJvbSB7dGJsbmFtZX0gZm9yIGtleSBzaGFyZSIpCgojbnRo
cmVhZHM9MTAKIwojdGhyZWFkcyA9IFtdCiNmb3IgdGhyZWFkbm8gaW4gcmFuZ2UobnRocmVh
ZHMpOgojICAgIHRibG5hbWUgPSBmInRibHt0aHJlYWRub30iCiMgICAgdCA9IHRocmVhZGlu
Zy5UaHJlYWQodGFyZ2V0PXRlc3RfbXVsdGl4YWN0LCBhcmdzPSh0YmxuYW1lLCkpCiMgICAg
dC5zdGFydCgpCiMgICAgdGhyZWFkcy5hcHBlbmQodCkKIwojZm9yIHRocmVhZG5vIGluIHJh
bmdlKG50aHJlYWRzKToKIyAgICB0aHJlYWRzW3RocmVhZG5vXS5qb2luKCkKCnRlc3RfbXVs
dGl4YWN0KHN5cy5hcmd2WzFdKQo=

--------------e3n9VcYGTb2KIaENa92noGrv--