On 2023/04/18 15:47, Landry Breuil wrote: > Le Tue, Apr 18, 2023 at 09:04:00AM +0100, Stuart Henderson a écrit : > > On 2023/04/18 09:05, Landry Breuil wrote: > > > What do postgresql users do when upgrading databases with extensions ? > > > Use the manual dump/restore way ? > > > > That's what I did last time I needed it. I thought the pkg-readme > > mentioned this but I just checked and I see it doesn't so at least we > > shoukd add that. > > You mean a mention to users of extensions that the pg_upgrade path might > not work in their case ?
exactly. > > The main tricky bit with that method is that you need to remember > > to dump before updating the OS, because new kernels fairly often > > won't run old binaries, there have been times I've had to mess around > > with the ports tree to build old postgresql on the new release to > > recover from that. > > I'm now used to dump all dbs prioir to sysupgrade :) > > > > > > RCS file: /cvs/ports/geo/postgis/Makefile,v > > .. > > > + PG_CONFIG=/usr/local/bin/postgresql-14/pg_config \ > > > > I'm not totally opposed to doing this with flavours, but then we have > > another multi-version thing used by other ports (so a bit like php and > > python), these are always a pain with @pkgpath etc. WANTLIB/LIB_DEPENDS > > might be annoying too. > > hence my idea of "not linked to the build" flavors; but that's gross. > > another alternative would be a distinct geo/postgis-previous port > installting only libs, to keep in sync with geo/postgis & bump at each > postgresql major upgrade. Not that pretty either.... > > now i understand why the postgresql debian repo ships the latest postgis > for all supported versions of postgresql :) :)
