> Troels,
>
> > I am working on getting rid of an old CentOS 7 server which runs
> > Postgres
> > 10+PostGIS 2.4.8, installed from the yum repository at
> > https://download.postgresql.org/pub/repos/yum/
> >
> > The server's databases are to be moved to a new Ubuntu 22 server
> > running Postgres
Troels,
> I am working on getting rid of an old CentOS 7 server which runs Postgres
> 10+PostGIS 2.4.8, installed from the yum repository at
> https://download.postgresql.org/pub/repos/yum/
>
> The server's databases are to be moved to a new Ubuntu 22 server running
> Postgres 15+PostGIS 3.4,
> On Nov 12, 2023, at 08:51, Troels Arvin wrote:
>
> OK, that sounds like I may need to plan with more downtime. But then again:
> If I can verify, that no code is using the aggregates/types which pg_restore
> complains about (such as the public.accum aggregate), shouldn't it be OK to
>
Hello,
Christophe Pettus wrote:
You usually have to follow a process of first, upgrading PostGIS to the highest
version that your current version of PostgreSQL supports, then upgrading
PostgreSQL to the highest version that supports that particular version of
PostGIS, and repeating the cycle
> On Nov 12, 2023, at 08:11, Troels Arvin via postgis-users
> wrote:
> Is my pg_dump->pg_restore plan simply not viable? If not, what other strategy
> should I employ?
PostGIS versions have specific PostgreSQL version requirements; the matrix is
here:
I am working on getting rid of an old CentOS 7 server which runs
Postgres 10+PostGIS 2.4.8, installed from the yum repository at
https://download.postgresql.org/pub/repos/yum/
The server's databases are to be moved to a new Ubuntu 22 server running
Postgres 15+PostGIS 3.4, installed from the
