Re: [postgis-users] restore problem

[Darrel Maddy]

The default appears to be custom. I did not change anything when I did this. I 
just accepted the defaults.

Darrel

From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Bborie Park
Sent: 10 November 2015 22:20
To: PostGIS Users Discussion 
Subject: Re: [postgis-users] restore problem

Odd. Looking at your error message again, it looks like the constraint is 
already in place by the time the data is getting loaded...

What are you restoring from? Tar, custom or text?

On Tue, Nov 10, 2015 at 2:16 PM, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:
Dear Bborie,

Apologies, I was obviously not clear – I was not asking about the problem 
itself, I can accept this is a difficult problem to resolve. I was simply 
asking for instruction on how to use your work around. This you kindly 
provided. Alas, however, even with the boxes checked, I get the same error and 
the raster table (dems) is empty.

Darrel

From: postgis-users 
[mailto:postgis-users-boun...@lists.osgeo.org]
 On Behalf Of Bborie Park
Sent: 10 November 2015 21:57

To: PostGIS Users Discussion 
mailto:postgis-users@lists.osgeo.org>>
Subject: Re: [postgis-users] restore problem

Given that the core problem has to do with the restore process' search_path, no 
amount of advice will help you get around the restrictions in place with the 
restore process without jumping into that process.

In pgAdmin, you can check the boxes "Pre-data" and "Data" of the "Restore 
Options #1" tab. This won't restore the post-data portion of the backup as 
restoring post-data should be causing your error.

You could also try unchecking the box "Exit On Error" of the "Restore Options 
#2" tab.

-bborie

On Tue, Nov 10, 2015 at 1:29 PM, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:
Dear Bborie,

Yikes – that makes little sense to me.  I am new to both postgres and postgis 
and would have hoped that backup and restore would have been simple push-button 
exercise!

As I am using PgAdmin I have no idea how to follow your instructions ☹

Anyone care to give me an idiots guide?

Sorry

Darrel


From: postgis-users 
[mailto:postgis-users-boun...@lists.osgeo.org]
 On Behalf Of Bborie Park
Sent: 10 November 2015 21:22
To: PostGIS Users Discussion 
mailto:postgis-users@lists.osgeo.org>>
Subject: Re: [postgis-users] restore problem

This problem arises because PostgreSQL sets the search path during the restore 
process. Unfortunately, the search path is quite restrictive.

You should be able to do your restore in three sections using pg_restore's 
--section flag.

The error looks like it has to be the post-data section, which you should 
output to a text file, change the "SET search_path" statements and then run 
through psql.

-bborie

On Tue, Nov 10, 2015 at 1:11 PM, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:
Dear all,

Like many here I suspect I want to keep a copy of my main databases held on my 
workstation, on my laptop. I used PgAdmin to backup the databases concerned 
(the backup files look about the size I was expecting)  but restore on my 
laptop did not successfully complete.  All my shp file tables restored without 
issues but my raster tables (these are tiled rasters) would not. Looking at the 
error in the restore window of PgAdmin this appears to be a problem with a 
function/constraint.

pg_restore: processing data for table "dems"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA dems 
postgres
pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
  ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.
QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
ARRAY[]::int[]);
CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
COPY dems, line 1: "1  
010100344034C0E0CCB1D51741806692F80C41..."


I did a quick search and found some old chatter on this issue but from the 
messages I read I would have expected this issue to have been cleared up in 
postgis 2 .

Obviously I cannot contemplate having mission critical data in a database which 
does not backup/restore correctly so I am assuming there is a fix which avoids 
this issue or there is another way to make a copy of the database for transfer 
elsewhere?

Once again any help would be gratefully received.

Best wishes

Darrel

ps.   Apologies for the string of questions I have asked lately – I will go 
silent once more shortly as I must move on to other things.

___
postgis-users mailing li

Re: [postgis-users] restore problem

[Bborie Park]

Odd. Looking at your error message again, it looks like the constraint is
already in place by the time the data is getting loaded...

What are you restoring from? Tar, custom or text?

On Tue, Nov 10, 2015 at 2:16 PM, Darrel Maddy 
wrote:

> Dear Bborie,
>
>
>
> Apologies, I was obviously not clear – I was not asking about the problem
> itself, I can accept this is a difficult problem to resolve. I was simply
> asking for instruction on how to use your work around. This you kindly
> provided. Alas, however, even with the boxes checked, I get the same error
> and the raster table (dems) is empty.
>
>
>
> Darrel
>
>
>
> *From:* postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] *On
> Behalf Of *Bborie Park
> *Sent:* 10 November 2015 21:57
>
> *To:* PostGIS Users Discussion 
> *Subject:* Re: [postgis-users] restore problem
>
>
>
> Given that the core problem has to do with the restore process'
> search_path, no amount of advice will help you get around the restrictions
> in place with the restore process without jumping into that process.
>
>
>
> In pgAdmin, you can check the boxes "Pre-data" and "Data" of the "Restore
> Options #1" tab. This won't restore the post-data portion of the backup as
> restoring post-data should be causing your error.
>
>
>
> You could also try unchecking the box "Exit On Error" of the "Restore
> Options #2" tab.
>
>
>
> -bborie
>
>
>
> On Tue, Nov 10, 2015 at 1:29 PM, Darrel Maddy <
> darrel.ma...@newcastle.ac.uk> wrote:
>
> Dear Bborie,
>
>
>
> Yikes – that makes little sense to me.  I am new to both postgres and
> postgis and would have hoped that backup and restore would have been simple
> push-button exercise!
>
>
>
> As I am using PgAdmin I have no idea how to follow your instructions L
>
>
>
> Anyone care to give me an idiots guide?
>
>
>
> Sorry
>
>
>
> Darrel
>
>
>
>
>
> *From:* postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] *On
> Behalf Of *Bborie Park
> *Sent:* 10 November 2015 21:22
> *To:* PostGIS Users Discussion 
> *Subject:* Re: [postgis-users] restore problem
>
>
>
> This problem arises because PostgreSQL sets the search path during the
> restore process. Unfortunately, the search path is quite restrictive.
>
>
>
> You should be able to do your restore in three sections using pg_restore's
> --section flag.
>
>
>
> The error looks like it has to be the post-data section, which you should
> output to a text file, change the "SET search_path" statements and then run
> through psql.
>
>
>
> -bborie
>
>
>
> On Tue, Nov 10, 2015 at 1:11 PM, Darrel Maddy <
> darrel.ma...@newcastle.ac.uk> wrote:
>
> Dear all,
>
>
>
> Like many here I suspect I want to keep a copy of my main databases held
> on my workstation, on my laptop. I used PgAdmin to backup the databases
> concerned (the backup files look about the size I was expecting)  but
> restore on my laptop did not successfully complete.  All my shp file tables
> restored without issues but my raster tables (these are tiled rasters)
> would not. Looking at the error in the restore window of PgAdmin this
> appears to be a problem with a function/constraint.
>
>
>
> pg_restore: processing data for table "dems"
>
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
>
> pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA
> dems postgres
>
> pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function
> st_bandmetadata(public.raster, integer[]) does not exist
>
> LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
>
>   ^
>
> HINT:  No function matches the given name and argument types. You might
> need to add explicit type casts.
>
> QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1,
> ARRAY[]::int[]);
>
> CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
>
> COPY dems, line 1: "1
> 010100344034C0E0CCB1D51741806692F80C41..."
>
>
>
>
>
> I did a quick search and found some old chatter on this issue but from the
> messages I read I would have expected this issue to have been cleared up in
> postgis 2 .
>
>
>
> Obviously I cannot contemplate having mission critical data in a database
> which does not backup/restore correctly so I am assuming there is a fix
> which avoids this issue or there is another way to make a copy of the
> database for transfer elsewhere?
>
>
>
> Once again any help would be gratefully received.
>
>
>
> Best wishes
>
>
>
> Darrel
>
>
>
> ps.   Apologies for the string of questions I have asked lately – I will
> go silent once more shortly as I must move on to other things.
>
>
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
>
>
>
>
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.or

Re: [postgis-users] restore problem

[Darrel Maddy]

Dear Bborie,

Apologies, I was obviously not clear – I was not asking about the problem 
itself, I can accept this is a difficult problem to resolve. I was simply 
asking for instruction on how to use your work around. This you kindly 
provided. Alas, however, even with the boxes checked, I get the same error and 
the raster table (dems) is empty.

Darrel

From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Bborie Park
Sent: 10 November 2015 21:57
To: PostGIS Users Discussion 
Subject: Re: [postgis-users] restore problem

Given that the core problem has to do with the restore process' search_path, no 
amount of advice will help you get around the restrictions in place with the 
restore process without jumping into that process.

In pgAdmin, you can check the boxes "Pre-data" and "Data" of the "Restore 
Options #1" tab. This won't restore the post-data portion of the backup as 
restoring post-data should be causing your error.

You could also try unchecking the box "Exit On Error" of the "Restore Options 
#2" tab.

-bborie

On Tue, Nov 10, 2015 at 1:29 PM, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:
Dear Bborie,

Yikes – that makes little sense to me.  I am new to both postgres and postgis 
and would have hoped that backup and restore would have been simple push-button 
exercise!

As I am using PgAdmin I have no idea how to follow your instructions ☹

Anyone care to give me an idiots guide?

Sorry

Darrel


From: postgis-users 
[mailto:postgis-users-boun...@lists.osgeo.org]
 On Behalf Of Bborie Park
Sent: 10 November 2015 21:22
To: PostGIS Users Discussion 
mailto:postgis-users@lists.osgeo.org>>
Subject: Re: [postgis-users] restore problem

This problem arises because PostgreSQL sets the search path during the restore 
process. Unfortunately, the search path is quite restrictive.

You should be able to do your restore in three sections using pg_restore's 
--section flag.

The error looks like it has to be the post-data section, which you should 
output to a text file, change the "SET search_path" statements and then run 
through psql.

-bborie

On Tue, Nov 10, 2015 at 1:11 PM, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:
Dear all,

Like many here I suspect I want to keep a copy of my main databases held on my 
workstation, on my laptop. I used PgAdmin to backup the databases concerned 
(the backup files look about the size I was expecting)  but restore on my 
laptop did not successfully complete.  All my shp file tables restored without 
issues but my raster tables (these are tiled rasters) would not. Looking at the 
error in the restore window of PgAdmin this appears to be a problem with a 
function/constraint.

pg_restore: processing data for table "dems"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA dems 
postgres
pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
  ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.
QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
ARRAY[]::int[]);
CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
COPY dems, line 1: "1  
010100344034C0E0CCB1D51741806692F80C41..."


I did a quick search and found some old chatter on this issue but from the 
messages I read I would have expected this issue to have been cleared up in 
postgis 2 .

Obviously I cannot contemplate having mission critical data in a database which 
does not backup/restore correctly so I am assuming there is a fix which avoids 
this issue or there is another way to make a copy of the database for transfer 
elsewhere?

Once again any help would be gratefully received.

Best wishes

Darrel

ps.   Apologies for the string of questions I have asked lately – I will go 
silent once more shortly as I must move on to other things.

___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users


___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

[Bborie Park]

Given that the core problem has to do with the restore process'
search_path, no amount of advice will help you get around the restrictions
in place with the restore process without jumping into that process.

In pgAdmin, you can check the boxes "Pre-data" and "Data" of the "Restore
Options #1" tab. This won't restore the post-data portion of the backup as
restoring post-data should be causing your error.

You could also try unchecking the box "Exit On Error" of the "Restore
Options #2" tab.

-bborie

On Tue, Nov 10, 2015 at 1:29 PM, Darrel Maddy 
wrote:

> Dear Bborie,
>
>
>
> Yikes – that makes little sense to me.  I am new to both postgres and
> postgis and would have hoped that backup and restore would have been simple
> push-button exercise!
>
>
>
> As I am using PgAdmin I have no idea how to follow your instructions L
>
>
>
> Anyone care to give me an idiots guide?
>
>
>
> Sorry
>
>
>
> Darrel
>
>
>
>
>
> *From:* postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] *On
> Behalf Of *Bborie Park
> *Sent:* 10 November 2015 21:22
> *To:* PostGIS Users Discussion 
> *Subject:* Re: [postgis-users] restore problem
>
>
>
> This problem arises because PostgreSQL sets the search path during the
> restore process. Unfortunately, the search path is quite restrictive.
>
>
>
> You should be able to do your restore in three sections using pg_restore's
> --section flag.
>
>
>
> The error looks like it has to be the post-data section, which you should
> output to a text file, change the "SET search_path" statements and then run
> through psql.
>
>
>
> -bborie
>
>
>
> On Tue, Nov 10, 2015 at 1:11 PM, Darrel Maddy <
> darrel.ma...@newcastle.ac.uk> wrote:
>
> Dear all,
>
>
>
> Like many here I suspect I want to keep a copy of my main databases held
> on my workstation, on my laptop. I used PgAdmin to backup the databases
> concerned (the backup files look about the size I was expecting)  but
> restore on my laptop did not successfully complete.  All my shp file tables
> restored without issues but my raster tables (these are tiled rasters)
> would not. Looking at the error in the restore window of PgAdmin this
> appears to be a problem with a function/constraint.
>
>
>
> pg_restore: processing data for table "dems"
>
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
>
> pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA
> dems postgres
>
> pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function
> st_bandmetadata(public.raster, integer[]) does not exist
>
> LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
>
>   ^
>
> HINT:  No function matches the given name and argument types. You might
> need to add explicit type casts.
>
> QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1,
> ARRAY[]::int[]);
>
> CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
>
> COPY dems, line 1: "1
> 010100344034C0E0CCB1D51741806692F80C41..."
>
>
>
>
>
> I did a quick search and found some old chatter on this issue but from the
> messages I read I would have expected this issue to have been cleared up in
> postgis 2 .
>
>
>
> Obviously I cannot contemplate having mission critical data in a database
> which does not backup/restore correctly so I am assuming there is a fix
> which avoids this issue or there is another way to make a copy of the
> database for transfer elsewhere?
>
>
>
> Once again any help would be gratefully received.
>
>
>
> Best wishes
>
>
>
> Darrel
>
>
>
> ps.   Apologies for the string of questions I have asked lately – I will
> go silent once more shortly as I must move on to other things.
>
>
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
>
>
>
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

[Darrel Maddy]

Hi Tim,

Yes, when I create the extension in an empty database  
st_bandmetadata(raster,integer) is listed as a function in the public schema.

Darrel

From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Tim Sutton
Sent: 10 November 2015 21:44
To: PostGIS Users Discussion 
Subject: Re: [postgis-users] restore problem

Hi

On 10 Nov 2015, at 23:33, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:

Hi Tim,

I am on windows and using the latest version 2.2 of postgis (and postgresql 
9.4). My original databases do not have pg_raster as an extension – I am 
assuming that is not required now?


I think it is anyway lumped in with postgis, but it certainly seems that the 
raster based functions are missing:

pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1


If you create an empty db, ensure that postgis extension is enabled can you 
check that it has st_bandmetadata present before doing the restore?

My cheat of loading postgis before doing the restore is a simpler workaround 
for Bborie’s process since the st_* functions from your backup (with their 
possibly incorrect lib paths) will be rejected if the functions are already 
installed, but the rest of the data in your dump *should* restore.

Regards

Tim




Darrel

From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Tim Sutton
Sent: 10 November 2015 21:30
To: PostGIS Users Discussion 
mailto:postgis-users@lists.osgeo.org>>
Subject: Re: [postgis-users] restore problem

Hi

On 10 Nov 2015, at 23:26, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:

Dear Tim,

Thanks for this suggestion.  I had assumed that the extensions were part of the 
backup as they appear on the manifest and indeed they appear in the restored 
database.

Alas this made no difference – I just tried it, creating the extension first 
before restore and I get exactly the same error.

And is pg_raster also installed in the target db before doing the restore? I 
don’t know if it is considered best practice by the postgis guru’s, but I 
usually install any extensions before doing a restore to deal with version 
differences between source and target systems gracefully...

Regards

Tim





Darrel




From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Tim Sutton
Sent: 10 November 2015 21:15
To: PostGIS Users Discussion 
mailto:postgis-users@lists.osgeo.org>>
Subject: Re: [postgis-users] restore problem

Hi
On 10 Nov 2015, at 23:11, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:

Dear all,

Like many here I suspect I want to keep a copy of my main databases held on my 
workstation, on my laptop. I used PgAdmin to backup the databases concerned 
(the backup files look about the size I was expecting)  but restore on my 
laptop did not successfully complete.  All my shp file tables restored without 
issues but my raster tables (these are tiled rasters) would not. Looking at the 
error in the restore window of PgAdmin this appears to be a problem with a 
function/constraint.

pg_restore: processing data for table "dems"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA dems 
postgres
pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
  ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.
QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
ARRAY[]::int[]);
CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
COPY dems, line 1: "1  
010100344034C0E0CCB1D51741806692F80C41..."


I did a quick search and found some old chatter on this issue but from the 
messages I read I would have expected this issue to have been cleared up in 
postgis 2 .

Obviously I cannot contemplate having mission critical data in a database which 
does not backup/restore correctly so I am assuming there is a fix which avoids 
this issue or there is another way to make a copy of the database for transfer 
elsewhere?


Have you enabled the PostGIS extension on the destination database before 
attempting to restore?

Regards

Tim




Once again any help would be gratefully received.

Best wishes

Darrel

ps.   Apologies for the string of questions I have asked lately – I will go 
silent once more shortly as I must move on to other things.
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-use

Re: [postgis-users] restore problem

[Tim Sutton]

Hi

> On 10 Nov 2015, at 23:33, Darrel Maddy  wrote:
> 
> Hi Tim,
> 
> I am on windows and using the latest version 2.2 of postgis (and postgresql 
> 9.4). My original databases do not have pg_raster as an extension – I am 
> assuming that is not required now?
> 

I think it is anyway lumped in with postgis, but it certainly seems that the 
raster based functions are missing:

pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1


If you create an empty db, ensure that postgis extension is enabled can you 
check that it has st_bandmetadata present before doing the restore?

My cheat of loading postgis before doing the restore is a simpler workaround 
for Bborie’s process since the st_* functions from your backup (with their 
possibly incorrect lib paths) will be rejected if the functions are already 
installed, but the rest of the data in your dump *should* restore.

Regards

Tim



> Darrel
> 
> From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org 
> ] On Behalf Of Tim Sutton
> Sent: 10 November 2015 21:30
> To: PostGIS Users Discussion  >
> Subject: Re: [postgis-users] restore problem
> 
> Hi
> 
> On 10 Nov 2015, at 23:26, Darrel Maddy  > wrote:
> 
> Dear Tim,
> 
> Thanks for this suggestion.  I had assumed that the extensions were part of 
> the backup as they appear on the manifest and indeed they appear in the 
> restored database.
> 
> Alas this made no difference – I just tried it, creating the extension first 
> before restore and I get exactly the same error.
> 
> And is pg_raster also installed in the target db before doing the restore? I 
> don’t know if it is considered best practice by the postgis guru’s, but I 
> usually install any extensions before doing a restore to deal with version 
> differences between source and target systems gracefully...
> 
> Regards
> 
> Tim
> 
> 
> 
> 
> Darrel
> 
> 
> 
> 
> From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org 
> ] On Behalf Of Tim Sutton
> Sent: 10 November 2015 21:15
> To: PostGIS Users Discussion  >
> Subject: Re: [postgis-users] restore problem
> 
> Hi
> On 10 Nov 2015, at 23:11, Darrel Maddy  > wrote:
> 
> Dear all,
> 
> Like many here I suspect I want to keep a copy of my main databases held on 
> my workstation, on my laptop. I used PgAdmin to backup the databases 
> concerned (the backup files look about the size I was expecting)  but restore 
> on my laptop did not successfully complete.  All my shp file tables restored 
> without issues but my raster tables (these are tiled rasters) would not. 
> Looking at the error in the restore window of PgAdmin this appears to be a 
> problem with a function/constraint.
> 
> pg_restore: processing data for table "dems"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA 
> dems postgres
> pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
> st_bandmetadata(public.raster, integer[]) does not exist
> LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
>   ^
> HINT:  No function matches the given name and argument types. You might need 
> to add explicit type casts.
> QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
> ARRAY[]::int[]);
> CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
> COPY dems, line 1: "1  
> 010100344034C0E0CCB1D51741806692F80C41..."
> 
> 
> I did a quick search and found some old chatter on this issue but from the 
> messages I read I would have expected this issue to have been cleared up in 
> postgis 2 .
> 
> Obviously I cannot contemplate having mission critical data in a database 
> which does not backup/restore correctly so I am assuming there is a fix which 
> avoids this issue or there is another way to make a copy of the database for 
> transfer elsewhere?
> 
> 
> Have you enabled the PostGIS extension on the destination database before 
> attempting to restore?
> 
> Regards
> 
> Tim
> 
> 
> 
> Once again any help would be gratefully received.
> 
> Best wishes
> 
> Darrel
> 
> ps.   Apologies for the string of questions I have asked lately – I will go 
> silent once more shortly as I must move on to other things.
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/postgis-users 
> 
> 

Re: [postgis-users] restore problem

[Darrel Maddy]

Hi Tim,

I am on windows and using the latest version 2.2 of postgis (and postgresql 
9.4). My original databases do not have pg_raster as an extension – I am 
assuming that is not required now?

Darrel

From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Tim Sutton
Sent: 10 November 2015 21:30
To: PostGIS Users Discussion 
Subject: Re: [postgis-users] restore problem

Hi

On 10 Nov 2015, at 23:26, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:

Dear Tim,

Thanks for this suggestion.  I had assumed that the extensions were part of the 
backup as they appear on the manifest and indeed they appear in the restored 
database.

Alas this made no difference – I just tried it, creating the extension first 
before restore and I get exactly the same error.

And is pg_raster also installed in the target db before doing the restore? I 
don’t know if it is considered best practice by the postgis guru’s, but I 
usually install any extensions before doing a restore to deal with version 
differences between source and target systems gracefully...

Regards

Tim




Darrel




From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Tim Sutton
Sent: 10 November 2015 21:15
To: PostGIS Users Discussion 
mailto:postgis-users@lists.osgeo.org>>
Subject: Re: [postgis-users] restore problem

Hi
On 10 Nov 2015, at 23:11, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:

Dear all,

Like many here I suspect I want to keep a copy of my main databases held on my 
workstation, on my laptop. I used PgAdmin to backup the databases concerned 
(the backup files look about the size I was expecting)  but restore on my 
laptop did not successfully complete.  All my shp file tables restored without 
issues but my raster tables (these are tiled rasters) would not. Looking at the 
error in the restore window of PgAdmin this appears to be a problem with a 
function/constraint.

pg_restore: processing data for table "dems"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA dems 
postgres
pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
  ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.
QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
ARRAY[]::int[]);
CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
COPY dems, line 1: "1  
010100344034C0E0CCB1D51741806692F80C41..."


I did a quick search and found some old chatter on this issue but from the 
messages I read I would have expected this issue to have been cleared up in 
postgis 2 .

Obviously I cannot contemplate having mission critical data in a database which 
does not backup/restore correctly so I am assuming there is a fix which avoids 
this issue or there is another way to make a copy of the database for transfer 
elsewhere?


Have you enabled the PostGIS extension on the destination database before 
attempting to restore?

Regards

Tim



Once again any help would be gratefully received.

Best wishes

Darrel

ps.   Apologies for the string of questions I have asked lately – I will go 
silent once more shortly as I must move on to other things.
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

—




Tim Sutton

Visit http://kartoza.com to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial

___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

—


[cid:image001.png@01D11BFF.7AE714F0]

Tim Sutton

Visit http://kartoza.com to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial

___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

[Tim Sutton]

Hi

> On 10 Nov 2015, at 23:26, Darrel Maddy  wrote:
> 
> Dear Tim,
> 
> Thanks for this suggestion.  I had assumed that the extensions were part of 
> the backup as they appear on the manifest and indeed they appear in the 
> restored database.
> 
> Alas this made no difference – I just tried it, creating the extension first 
> before restore and I get exactly the same error.

And is pg_raster also installed in the target db before doing the restore? I 
don’t know if it is considered best practice by the postgis guru’s, but I 
usually install any extensions before doing a restore to deal with version 
differences between source and target systems gracefully...

Regards

Tim


> 
> Darrel
> 
> 
> 
> 
> From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org 
> ] On Behalf Of Tim Sutton
> Sent: 10 November 2015 21:15
> To: PostGIS Users Discussion  >
> Subject: Re: [postgis-users] restore problem
> 
> Hi
> On 10 Nov 2015, at 23:11, Darrel Maddy  > wrote:
> 
> Dear all,
> 
> Like many here I suspect I want to keep a copy of my main databases held on 
> my workstation, on my laptop. I used PgAdmin to backup the databases 
> concerned (the backup files look about the size I was expecting)  but restore 
> on my laptop did not successfully complete.  All my shp file tables restored 
> without issues but my raster tables (these are tiled rasters) would not. 
> Looking at the error in the restore window of PgAdmin this appears to be a 
> problem with a function/constraint.
> 
> pg_restore: processing data for table "dems"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA 
> dems postgres
> pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
> st_bandmetadata(public.raster, integer[]) does not exist
> LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
>   ^
> HINT:  No function matches the given name and argument types. You might need 
> to add explicit type casts.
> QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
> ARRAY[]::int[]);
> CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
> COPY dems, line 1: "1  
> 010100344034C0E0CCB1D51741806692F80C41..."
> 
> 
> I did a quick search and found some old chatter on this issue but from the 
> messages I read I would have expected this issue to have been cleared up in 
> postgis 2 .
> 
> Obviously I cannot contemplate having mission critical data in a database 
> which does not backup/restore correctly so I am assuming there is a fix which 
> avoids this issue or there is another way to make a copy of the database for 
> transfer elsewhere?
> 
> 
> Have you enabled the PostGIS extension on the destination database before 
> attempting to restore?
> 
> Regards
> 
> Tim
> 
> 
> Once again any help would be gratefully received.
> 
> Best wishes
> 
> Darrel
> 
> ps.   Apologies for the string of questions I have asked lately – I will go 
> silent once more shortly as I must move on to other things.
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/postgis-users 
> 
> 
> —
> 
> 
> 
> 
> 
> Tim Sutton
> 
> Visit http://kartoza.com  to find out about open source:
> 
> * Desktop GIS programming services
> * Geospatial web development
> * GIS Training
> * Consulting Services
> 
> Skype: timlinux Irc: timlinux on #qgis at freenode.net 
> Tim is a member of the QGIS Project Steering Committee
> 
> Kartoza is a merger between Linfiniti and Afrispatial
> 
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/postgis-users 
> 
—





Tim Sutton

Visit http://kartoza.com  to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

[Darrel Maddy]

Dear Bborie,

Yikes – that makes little sense to me.  I am new to both postgres and postgis 
and would have hoped that backup and restore would have been simple push-button 
exercise!

As I am using PgAdmin I have no idea how to follow your instructions ☹

Anyone care to give me an idiots guide?

Sorry

Darrel


From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Bborie Park
Sent: 10 November 2015 21:22
To: PostGIS Users Discussion 
Subject: Re: [postgis-users] restore problem

This problem arises because PostgreSQL sets the search path during the restore 
process. Unfortunately, the search path is quite restrictive.

You should be able to do your restore in three sections using pg_restore's 
--section flag.

The error looks like it has to be the post-data section, which you should 
output to a text file, change the "SET search_path" statements and then run 
through psql.

-bborie

On Tue, Nov 10, 2015 at 1:11 PM, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:
Dear all,

Like many here I suspect I want to keep a copy of my main databases held on my 
workstation, on my laptop. I used PgAdmin to backup the databases concerned 
(the backup files look about the size I was expecting)  but restore on my 
laptop did not successfully complete.  All my shp file tables restored without 
issues but my raster tables (these are tiled rasters) would not. Looking at the 
error in the restore window of PgAdmin this appears to be a problem with a 
function/constraint.

pg_restore: processing data for table "dems"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA dems 
postgres
pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
  ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.
QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
ARRAY[]::int[]);
CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
COPY dems, line 1: "1  
010100344034C0E0CCB1D51741806692F80C41..."


I did a quick search and found some old chatter on this issue but from the 
messages I read I would have expected this issue to have been cleared up in 
postgis 2 .

Obviously I cannot contemplate having mission critical data in a database which 
does not backup/restore correctly so I am assuming there is a fix which avoids 
this issue or there is another way to make a copy of the database for transfer 
elsewhere?

Once again any help would be gratefully received.

Best wishes

Darrel

ps.   Apologies for the string of questions I have asked lately – I will go 
silent once more shortly as I must move on to other things.

___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

[Darrel Maddy]

Dear Tim,

Thanks for this suggestion.  I had assumed that the extensions were part of the 
backup as they appear on the manifest and indeed they appear in the restored 
database.

Alas this made no difference – I just tried it, creating the extension first 
before restore and I get exactly the same error.

Darrel




From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of 
Tim Sutton
Sent: 10 November 2015 21:15
To: PostGIS Users Discussion 
Subject: Re: [postgis-users] restore problem

Hi
On 10 Nov 2015, at 23:11, Darrel Maddy 
mailto:darrel.ma...@newcastle.ac.uk>> wrote:

Dear all,

Like many here I suspect I want to keep a copy of my main databases held on my 
workstation, on my laptop. I used PgAdmin to backup the databases concerned 
(the backup files look about the size I was expecting)  but restore on my 
laptop did not successfully complete.  All my shp file tables restored without 
issues but my raster tables (these are tiled rasters) would not. Looking at the 
error in the restore window of PgAdmin this appears to be a problem with a 
function/constraint.

pg_restore: processing data for table "dems"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA dems 
postgres
pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
  ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.
QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
ARRAY[]::int[]);
CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
COPY dems, line 1: "1  
010100344034C0E0CCB1D51741806692F80C41..."


I did a quick search and found some old chatter on this issue but from the 
messages I read I would have expected this issue to have been cleared up in 
postgis 2 .

Obviously I cannot contemplate having mission critical data in a database which 
does not backup/restore correctly so I am assuming there is a fix which avoids 
this issue or there is another way to make a copy of the database for transfer 
elsewhere?


Have you enabled the PostGIS extension on the destination database before 
attempting to restore?

Regards

Tim


Once again any help would be gratefully received.

Best wishes

Darrel

ps.   Apologies for the string of questions I have asked lately – I will go 
silent once more shortly as I must move on to other things.
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

—


[cid:image001.png@01D11BFE.66AE30F0]

Tim Sutton

Visit http://kartoza.com to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial

___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

[Bborie Park]

This problem arises because PostgreSQL sets the search path during the
restore process. Unfortunately, the search path is quite restrictive.

You should be able to do your restore in three sections using pg_restore's
--section flag.

The error looks like it has to be the post-data section, which you should
output to a text file, change the "SET search_path" statements and then run
through psql.

-bborie

On Tue, Nov 10, 2015 at 1:11 PM, Darrel Maddy 
wrote:

> Dear all,
>
>
>
> Like many here I suspect I want to keep a copy of my main databases held
> on my workstation, on my laptop. I used PgAdmin to backup the databases
> concerned (the backup files look about the size I was expecting)  but
> restore on my laptop did not successfully complete.  All my shp file tables
> restored without issues but my raster tables (these are tiled rasters)
> would not. Looking at the error in the restore window of PgAdmin this
> appears to be a problem with a function/constraint.
>
>
>
> pg_restore: processing data for table "dems"
>
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
>
> pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA
> dems postgres
>
> pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function
> st_bandmetadata(public.raster, integer[]) does not exist
>
> LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
>
>   ^
>
> HINT:  No function matches the given name and argument types. You might
> need to add explicit type casts.
>
> QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1,
> ARRAY[]::int[]);
>
> CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
>
> COPY dems, line 1: "1
> 010100344034C0E0CCB1D51741806692F80C41..."
>
>
>
>
>
> I did a quick search and found some old chatter on this issue but from the
> messages I read I would have expected this issue to have been cleared up in
> postgis 2 .
>
>
>
> Obviously I cannot contemplate having mission critical data in a database
> which does not backup/restore correctly so I am assuming there is a fix
> which avoids this issue or there is another way to make a copy of the
> database for transfer elsewhere?
>
>
>
> Once again any help would be gratefully received.
>
>
>
> Best wishes
>
>
>
> Darrel
>
>
>
> ps.   Apologies for the string of questions I have asked lately – I will
> go silent once more shortly as I must move on to other things.
>
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Re: [postgis-users] restore problem

[Tim Sutton]

Hi
> On 10 Nov 2015, at 23:11, Darrel Maddy  wrote:
> 
> Dear all,
> 
> Like many here I suspect I want to keep a copy of my main databases held on 
> my workstation, on my laptop. I used PgAdmin to backup the databases 
> concerned (the backup files look about the size I was expecting)  but restore 
> on my laptop did not successfully complete.  All my shp file tables restored 
> without issues but my raster tables (these are tiled rasters) would not. 
> Looking at the error in the restore window of PgAdmin this appears to be a 
> problem with a function/constraint.
> 
> pg_restore: processing data for table "dems"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA 
> dems postgres
> pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
> st_bandmetadata(public.raster, integer[]) does not exist
> LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
>   ^
> HINT:  No function matches the given name and argument types. You might need 
> to add explicit type casts.
> QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
> ARRAY[]::int[]);
> CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
> COPY dems, line 1: "1  
> 010100344034C0E0CCB1D51741806692F80C41..."
> 
> 
> I did a quick search and found some old chatter on this issue but from the 
> messages I read I would have expected this issue to have been cleared up in 
> postgis 2 .
> 
> Obviously I cannot contemplate having mission critical data in a database 
> which does not backup/restore correctly so I am assuming there is a fix which 
> avoids this issue or there is another way to make a copy of the database for 
> transfer elsewhere?
> 

Have you enabled the PostGIS extension on the destination database before 
attempting to restore?

Regards

Tim

> Once again any help would be gratefully received.
> 
> Best wishes
> 
> Darrel
> 
> ps.   Apologies for the string of questions I have asked lately – I will go 
> silent once more shortly as I must move on to other things.
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/postgis-users 
> 
—





Tim Sutton

Visit http://kartoza.com  to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

[postgis-users] restore problem

[Darrel Maddy]

Dear all,

Like many here I suspect I want to keep a copy of my main databases held on my 
workstation, on my laptop. I used PgAdmin to backup the databases concerned 
(the backup files look about the size I was expecting)  but restore on my 
laptop did not successfully complete.  All my shp file tables restored without 
issues but my raster tables (these are tiled rasters) would not. Looking at the 
error in the restore window of PgAdmin this appears to be a problem with a 
function/constraint.

pg_restore: processing data for table "dems"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3459; 0 94054 TABLE DATA dems 
postgres
pg_restore: [archiver (db)] COPY failed for table "dems": ERROR:  function 
st_bandmetadata(public.raster, integer[]) does not exist
LINE 1:  SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1...
  ^
HINT:  No function matches the given name and argument types. You might need to 
add explicit type casts.
QUERY:   SELECT array_agg(pixeltype)::text[] FROM st_bandmetadata($1, 
ARRAY[]::int[]);
CONTEXT:  SQL function "_raster_constraint_pixel_types" during inlining
COPY dems, line 1: "1  
010100344034C0E0CCB1D51741806692F80C41..."


I did a quick search and found some old chatter on this issue but from the 
messages I read I would have expected this issue to have been cleared up in 
postgis 2 .

Obviously I cannot contemplate having mission critical data in a database which 
does not backup/restore correctly so I am assuming there is a fix which avoids 
this issue or there is another way to make a copy of the database for transfer 
elsewhere?

Once again any help would be gratefully received.

Best wishes

Darrel

ps.   Apologies for the string of questions I have asked lately - I will go 
silent once more shortly as I must move on to other things.
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users