On Mon, Aug 17, 2020 at 1:44 PM Dave Page <dp...@pgadmin.org> wrote: > > > On Mon, Aug 17, 2020 at 11:19 AM Magnus Hagander <mag...@hagander.net> > wrote: > >> >> >> On Fri, Aug 14, 2020 at 3:00 PM Bruce Momjian <br...@momjian.us> wrote: >> >>> On Tue, Aug 11, 2020 at 02:58:30PM +0200, Magnus Hagander wrote: >>> > On Tue, Aug 4, 2020 at 11:42 AM Dave Page <dp...@pgadmin.org> wrote: >>> > That would require fairly large changes to the installer to allow >>> it to >>> > login to the database server (whether that would work would >>> be dependent on >>> > how pg_hba.conf is configured), and also assumes that the ICU ABI >>> hasn't >>> > changed between releases. It would also require some hacky >>> renaming of >>> > DLLs, as they have the version number in them. >>> > >>> > I assumed it had code for that stuff already. Mainly because I assumed >>> it >>> > supported doing pg_upgrade, which requires similar things no? >>> >> > No, the installers don't support pg_upgrade directly. They ship it of > course, and the user can manually run it, but the installers won't do that, > and have no ability to login to a cluster except during the post-initdb > phase. >
Oh, I just assumed it did :) If it doesn't, I think shipping with a modern ICU is a much smaller problem really... While pg_upgrade requires having the old and new cluster software in >>> place, I don't think it helps allowing different ICU versions for each >>> cluster. >> >> >> Depends on where they are installed (and disclaimer, I don't know how the >> windows installers do that). But as long as the ICU libraries are installed >> in separate locations for the two versions, which I *think* they are or at >> least used to be, it shouldn't have an effect on this in either direction. >> > > They are. > Good. So putting both in wouldn't break things. That argument really only holds for different versions, not for different >> clusters of the same version. But I don't think the installers (natively) >> supports multiple clusters of the same version anyway. >> > > They don't. You'd need to manually init a new cluster and register a new > server instance. The installer only has any knowledge of the cluster it > sets up. > I'd say that's "unsupported enough" to not be a scenario one has to consider. >> The tricky thing is if you want to allow the user to *choose* which ICU >> version should be used with postgres version <x>. Because then the user >> might also expect an upgrade-path wherein they only upgrade the icu library >> on an existing install... >> >> >>> I guess you can argue that if you know the user is _not_ going >>> to be using pg_upgrade, then a new ICU version should be used for the >>> new cluster. >>> >> >> Yes, that's exactly the argument I meant :) If the user got the option to >> "pick version of ICU: <old>, <new>", with a comment saying "pick old only >> if you plan to do a pg_upgrade based upgrade of a different cluster, or if >> this instance should participate in replication with a node using <old>", >> that would probably help for the vast majority of cases. And of course, if >> the installer through other options can determine with certainty that it's >> going to be running pg_upgrade for the user, then it can reword the dialog >> based on that (that is, it should still allow the user to pick the new >> version, as long as they know that their indexes are going to need >> reindexing) >> > > That seems like a very hacky and extremely user-unfriendly approach. How > many users are going to understand options in the installer to deal with > that, or want to go decode the ICU filenames on their existing > installations (which our installers may not actually know about) to figure > out what their current version is? > That was more if the installer actually handles the whole chain. It clearly doesn't today (since it doesn't support upgrades), I agree this might definitely be overkill. But then also I don't really see the problem with just putting a new version of ICU in with the newer versions of PostgreSQL. That's just puts the user in the same position as they are with any other platform wrt manual pg_upgrade runs. > > I would suggest that the better way to handle this would be for pg_upgrade > to (somehow) check the ICU version on the old and new clusters and if > there's a mismatch perform a reindex of any ICU based indexes. I suspect > that may require that the server exposes the ICU version though. That way, > the installers could freely upgrade the ICU version with a new major > release. > Having pg_upgrade spit out a script that does reindex specifically on the indexes required would certainly be useful in the generic case, and help others as well. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
