Re: POC: make mxidoff 64 bits

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Subject: Re: POC: make mxidoff 64 bits
Date: 2025-12-04 15:33:47
Message-ID: CACG=eza-JrdrWqCu2zR05+jWPSHO2CO9hrHTYBNF9LSd4dzXGw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 4 Dec 2025 at 13:39, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> However, that doesn't hold for pg_upgrade. pg_upgrade will try to read
> all the multixids. So we need to make the multixact reading code
> tolerant of the situations that could be present after a crash. I think
> the right philosophy here is that we try to read all the old multixids,
> and do our best to interpret them the same way that the old server
> would.

Something like attached?

Now previous scheme of upgrade with the bytes joggling start
looking not so bad. Just a funny thought that came to my mind.

Perhaps we should check that all the files exist and have the correct

sizes in the pre-check stage

Not sure about it. Because SLRU does not support "holes", simply
checking if the first and last multixacts exist will be enough. But
we'll do it anyway in a real conversion.

PFA to start a conversation.

--
Best regards,
Maxim Orlov.

Attachment Content-Type Size
0001-rough-draft-of-skipping-bogus-offsets.patch.txt text/plain 4.3 KB
0002-Check-is-first-and-last-multis-exists.patch.txt text/plain 2.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-12-04 15:33:52 Re: Segmentation fault on proc exit after dshash_find_or_insert
Previous Message Jelte Fennema-Nio 2025-12-04 15:29:55 Re: Safer hash table initialization macro