Wow thank you very much, so the way I install <font><span style="line-height:normal;background-color:rgba(255,255,255,0)">spatial_ref_sys is with </span></font><div><font><span style="line-height:normal"><br></span></font></div>
<div><font><span style="line-height:normal">psql -d example -f "path to </span><span style="line-height:normal;background-color:rgba(255,255,255,0)">spatial_ref_sys.sql"</span></font></div><div><font><span style="line-height:normal"><span style><br>
</span></span></font></div><div><font><span style="line-height:normal;background-color:rgba(255,255,255,0)"></span><span style="line-height:normal"><span style>?????</span></span></font></div><div><font><span style="line-height:normal"><span style><br>
</span></span></font></div><div><font><span style="line-height:normal"><span style>And how do I delete the database completely? I did a DROP database but I think it is not enough </span></span></font></div><div><font><span style="line-height:normal"><span style><br>
</span></span></font></div><div><font><span style="line-height:normal"><span style>Thank you very much for your help <span></span><br></span></span></font><br>On Tuesday, July 16, 2013, Racine, Sylvain wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
See below...<br>
<br>
<div>Le 2013-07-16 17:03, Marcos Cano a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>thank you very much for your help and time, so my case is
the second one... but that does not matter now because after
doing the whole process of dumping and perl_restore, it is
not working, some databases are empty after the dump and i
see a lot of :<br>
<br>
ERROR: constraint "spatial_ref_sys_srid_check" of relation
"spatial_ref_sys" does not exist<br>
ERROR: constraint "spatial_ref_sys_pkey" of relation
"spatial_ref_sys" does not exist<br>
</div>
</div>
</div>
</blockquote>
'spatial_ref_sys' table must be dumped in your backup file. If it's
not, install spatial_ref_sys.sql script from your new database
version to remove those errors. <br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
ERROR: type "histogram2d" already exists<br>
ERROR: function "al_set_stat_celplan" already exists with
same argument types<br>
ERROR: function "al_set_stat_leasing" already exists with
same argument types<br>
ERROR: function "round_time" already exists with same
argument types<br>
ERROR: function "array_accum" already exists with same
argument types<br>
ERROR: relation "ad_id_seq" already exists<br>
ERROR: relation "agosto_2012" already exists<br>
<br>
</div>
</div>
</div>
</blockquote>
It's sound like you try to restore to a database you already tried
to restore a PostGIS database and you just deleted the tables before
restoring another one.... If your restore failed, drop completely
the new database and create a new one from scratch. The
<a href="http://postgis_restore.pl" target="_blank">postgis_restore.pl</a> script not just restore tables, but also any
PGSQL functions, sequences and some other stuffs. I think that why
your restoration failed.<br>
<br>
I understand that you have one or many large databases to upgrade. I
saw a progression in the resolution of your difficults. But, because
new difficults always appear, I'm not sure you will have enough
time to resolve all the problems to get a safety upgrade. If you
need faster help and/or want professionnal advices, I can help you
using remote as SSH.<br>
<br>
Regards<br>
<br>
--<br>
Sylvain Racine, geomatic technician and PHP programmer<br>
50, St-Hubert, #5<br>
Granby, Quebec, Canada<br>
Phone: +1 (450) 770-9974<br>
email: <a href="javascript:_e({}, 'cvml', 'sracine@igreffe.net');" target="_blank">sracine@igreffe.net</a><br>
Site: <a href="http://www.igreffe.net" target="_blank">http://www.igreffe.net</a> (only in French)<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>in the logfile<br>
<br>
</div>
so idk why im not able to really (dump or restore??) i think it
might be the restore process, as i obviously dont have full
control over the large script <a href="http://postgis_restore.pl" target="_blank">postgis_restore.pl</a> <br>
<br>
<br>
<div>
<div><br>
</div>
</div>
</div>
<div><br>
<br>
<div>On Fri, Jul 12, 2013 at 8:52 PM,
Racine, Sylvain <span dir="ltr"><<a>syracine@sympatico.ca</a>></span>
wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> I answer to your
first question about how to change PATH variable without
screwing it.<br>
<br>
There is another way to change PATH variable, but only for
one account at the time. You have to add the following
lines to a file called .bash_profile (don't miss the dot
(.) at the beginning) located in your $HOME or ~
directory:<br>
<br>
PATH=/usr/local/pgsql9.2.4/bin/:$PATH<br>
export PATH<br>
<br>
By this way, you only add a path to the PATH variable
without removing the old pgsql path (who seem be
/usr/local/pgsql/bin/ in your system). You might be aware
that this way can make confusion in order to know which
version of pgsql command will be called. I'm not sure, but
I think that the order of the PATH command is as we read
it, e.g. from left to right and from top to bottom. That's
why I add pgsql9.2.4 path at the very beginning of the
PATH variable. Remember also that the pgsql9.2.4 path will
be accessible only for the account where you put your
.bash_profile file.<br>
<br>
Your second question is about to put or not the database
in read-only mode before pg_dump -Fc. I want to tell you
that you learned me a new feature in PostgreSQL that I
didn't hear before. But, I read informations on internet
and I learned that it's really a PostgreSQL feature.<br>
<br>
I suppose you talk about the source database. There are
some informations I don't know about your installation.
How large is your setup? If you have a small database in
a university department where you can limit the access of
the database to only one or two computers located in the
same school room , it's obvious that you just need to turn
off those computers, backup the data (pg_dump -Fc) on the
server without read-only mode, restore them to the new
database and set the new connection of those computers
before the users can access the new database and that's
it. But if it's a database who is the back-end of a large
web site with many redundant servers, I suppose in that
case that it's better first to put the web site offline,
disconnect all the users from the source database before
doing pg_dump -Fc on the master DB, restoring the data,
propagate the new connection link, make some "home" tests
and re-open the web site after. I think that the question
to put or not in read-only mode your PostgreSQL database
before your pg_dump -Fc is about to know if you have or
not the control on the access of the database. It's
obvious that you should not have modifications of the data
in your source database between the moment you back them
up and you restore them to your new database.<br>
<br>
In my experience, I back up and restore regularly a small
database on a desktop computer in a small office. I do it
when users are not there and I never put PostgreSQL in
read-only mode. If you experience the situation of a large
web site, I think it's really a good choice to ask your
question to and to be helped by a professionnal PostgreSQL
specialist as EnterpriseDB.<br>
<br>
Hope it will be useful<br>
<br>
Sylvain Racine<br>
<br>
<br>
<div>Le 2013-07-12 13:51, Marcos Cano a écrit :<br>
</div>
<div>
<div></div></div></div></blockquote></div></div></blockquote></div>
</blockquote></div>