Re: mxid and mxoff wraparound issues in pg_upgrade - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: mxid and mxoff wraparound issues in pg_upgrade
Date
Msg-id f705e045-8c0c-4cec-938a-d911dec2c5ea@iki.fi
Whole thread Raw
In response to Re: mxid and mxoff wraparound issues in pg_upgrade  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On 05/11/2025 14:15, Heikki Linnakangas wrote:
> I propose the attached fix. It adds separate booleans to pg_resetwal to 
> track whether -m or -O option was given, and allows 0 for the next 
> multixid and UINT32_MAX for next multixact offset.

Committed, with one more change:

I replaced strtoul() with strtoi64() in parsing the multixact offset. 
strtoul() silently casts negative values to positive ones, which means 
that even before this patch, we accepted any negative value, except for 
-1 which was checked specifically. That's bogus, and with the previous 
patch I posted, we would start accepting -1 too, which makes it even 
worse.  By using strtoi64() and converting to uint32 explicitly, we now 
check and error out on all negative values.

We have the same issue with all the other flags that use strtoul(), but 
I didn't want to touch those right now, especially in back-branches. But 
I also didn't want to start accepting -1 for -O. On 'master' I think it 
would make sense to tighten up the other flags, too. I don't plan to 
work on that myself but would be happy to review if someone writes the 
patch.

I didn't commit the new pg_upgrade test case, but many thanks for 
providing it. It was very helpful in demonstrating the problem.

- Heikki




pgsql-hackers by date:

Previous
From: Shlok Kyal
Date:
Subject: Re: How can end users know the cause of LR slot sync delays?
Next
From: Mircea Cadariu
Date:
Subject: Re: pgsql: Drop unnamed portal immediately after execution to completion