Re: Catversion bumps during beta (was Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Catversion bumps during beta (was Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring)
Date
Msg-id 1185861.1790093551@sss.pgh.pa.us
Whole thread
In response to Catversion bumps during beta (was Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Catversion bumps during beta (was Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring)
List pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> I don't really mind catversion bumps during the beta period in general, 
> I'm in the camp that if there's a change that would make the release 
> better and it's not particularly risky, it's better to still sneak it in.

> I feel I might be in the minority with that view though. Historically, 
> we've avoided fixes that need catversion bumps late in the beta period, 
> so that beta-testers don't need to pg_upgrade. I think that's a poor 
> tradeoff, but if we're changing long-standing policy, the RMT probably 
> isn't the right group for that. So, how do others feel?

IMO, we've avoided it, but that's not a blanket policy against it.
Making beta testers exercise pg_upgrade isn't without benefit.

IIUC, the issue here is that we think these new-in-v19 functions are
suboptimally named, and if we don't change the names now then we're
stuck with them.  So I'm okay with a post-beta4 catversion bump
to do that.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Teach pg_upgrade to deal with invalid databases
Next
From: Nathan Bossart
Date:
Subject: Re: Teach pg_upgrade to deal with invalid databases