On Thu, Apr 04, 2019 at 08:33:47AM +0200, Paolo Cavallini wrote:
> solved by forcing install of official deb postgresql-9.4-postgis-2.1
> from there on, things work. so, why does apt remove the needed package?
> it seems appropriate to me keeping it until postgresql 9.4 is purged.
> am I missing s
Hi all
On 03/04/19 20:15, Paolo Cavallini wrote:
> Hi again
>
> On 03/04/19 19:44, Sandro Santilli wrote:
>
>> This is unexpected, if 2.3.1 was _really_ installed.
>> Can it be you manually installed 2.1.4 again on top
>> of 2.3.1 ? What version you update to depends on
>> the contents of postgi
Hi again
On 03/04/19 19:44, Sandro Santilli wrote:
> This is unexpected, if 2.3.1 was _really_ installed.
> Can it be you manually installed 2.1.4 again on top
> of 2.3.1 ? What version you update to depends on
> the contents of postgis.control file.
to do so I think the only way is to recompile
Hi all
>> On 03/04/19 19:04, Sandro Santilli wrote:
>>> Can you show the ALTER EXTENSION command you're issuing and the
>>> error you're getting ? Also please show the output of
>>>
>>> SELECT postgis_full_version();
select postgis_full_version();
ERRORE: caricamento della libreria
"/usr/lib/
Hi Paul,
On 03/04/19 19:42, Paul Ramsey wrote:
> It can perhaps be fixed by copying postgis—2.3.0--2.3.1.sql (or, really, any
> of the extension upgrade scripts) to postgis—2.1.4–2.3.1.sql
cp /usr/share/postgresql/9.6/extension/postgis--2.1.4--2.3.1.sql
/usr/share/postgresql/9.4/extension/
al
On Wed, Apr 03, 2019 at 07:34:33PM +0200, Paolo Cavallini wrote:
>
>
> On 03/04/19 19:04, Sandro Santilli wrote:
> > Can you show the ALTER EXTENSION command you're issuing and the
> > error you're getting ? Also please show the output of
> >
> > SELECT postgis_full_version();
>
> I tried bot
Well, this speaks to not having micro version numbers in the extension
versioning, for sure.
Also, potentially for having a global source version, an idea that we’d have to
add to the PgSQL extension system, so a script like postgis—ANY—2.3.sql could
take a best-effort run at upgrading any prior
On 03/04/19 19:04, Sandro Santilli wrote:
> Can you show the ALTER EXTENSION command you're issuing and the
> error you're getting ? Also please show the output of
>
> SELECT postgis_full_version();
I tried both
ALTER EXTENSION postgis UPDATE;
with something like
the 2.1.4 version is already
On Wed, Apr 03, 2019 at 06:52:40PM +0200, Paolo Cavallini wrote:
> On 03/04/19 18:32, Sandro Santilli wrote:
>
> > In theory, any such function would be replaced by running
> > a soft upgrade of PostGIS in that database.
>
> how do I do a soft upgrade, given that alter extension says the function
Hi again
On 03/04/19 18:32, Sandro Santilli wrote:
> So, I guess what happens is that pg_dump wants to use the
> "canonical output" functions for the geometry types of some
> database (or why would pg_dump require that library?).
>
> Can you confirm the above ? Are you POSITIVE the database
> yo
Hi
On 03/04/19 18:32, Sandro Santilli wrote:
> Very interesting case, as it shows a problem with the idea
> that dropping minor version from the SO would fix this kind
> of problem.
>
> So, I guess what happens is that pg_dump wants to use the
> "canonical output" functions for the geometry type
On Wed, Apr 03, 2019 at 06:20:22PM +0200, Paolo Cavallini wrote:
> On 03/04/19 18:10, Paul Ramsey wrote:
> >> On Apr 3, 2019, at 9:08 AM, Paolo Cavallini wrote:
> >>
> >> Hi all,
> >> I'm on a difficult situation: a debian sever with a pg9.4/pgis2.1 db has
> >> been upgraded to stretch, therefore
same error, mismatching versions
# pg_dropcluster --stop 9.6 main
# pg_upgradecluster 9.4 main
On 03/04/19 18:23, Paul Ramsey wrote:
> Use a pg_upgrade process instead of a pg_dump. You should be able to that
> with just the old data area and the new server software.
>
>> On Apr 3, 2019, at 9:2
Use a pg_upgrade process instead of a pg_dump. You should be able to that with
just the old data area and the new server software.
> On Apr 3, 2019, at 9:21 AM, Paolo Cavallini wrote:
>
> I mean: server versions don't match (9.4 vs 9.6)
>
> On 03/04/19 18:20, Paolo Cavallini wrote:
>> done alr
I mean: server versions don't match (9.4 vs 9.6)
On 03/04/19 18:20, Paolo Cavallini wrote:
> done already, but it complains that the versions don't match
> thanks
>
> On 03/04/19 18:10, Paul Ramsey wrote:
>> Put a symlink to the postgis-2.3.so file, named as postgis-2.1.so
>>
>> P
>>
>>> On Apr 3
done already, but it complains that the versions don't match
thanks
On 03/04/19 18:10, Paul Ramsey wrote:
> Put a symlink to the postgis-2.3.so file, named as postgis-2.1.so
>
> P
>
>> On Apr 3, 2019, at 9:08 AM, Paolo Cavallini wrote:
>>
>> Hi all,
>> I'm on a difficult situation: a debian sev
Put a symlink to the postgis-2.3.so file, named as postgis-2.1.so
P
> On Apr 3, 2019, at 9:08 AM, Paolo Cavallini wrote:
>
> Hi all,
> I'm on a difficult situation: a debian sever with a pg9.4/pgis2.1 db has
> been upgraded to stretch, therefore to pg9.6/pgis2.3. Now pg_dump will
> complain of
Hi all,
I'm on a difficult situation: a debian sever with a pg9.4/pgis2.1 db has
been upgraded to stretch, therefore to pg9.6/pgis2.3. Now pg_dump will
complain of the missing pgis2.1 lib, even if I dump only a non public
(thus without pgis functions) schema.
How could I fix this?
Thanks a lot.
--
18 matches
Mail list logo