<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    See below...<br>
    <br>
    <div class="moz-cite-prefix">Le 2013-07-17 15:02, Marcos Cano a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CAP2RsaL_-HNhG3dLajFzPGF+5vFPNX7DYwkL89bGBqNZC1xzhg@mail.gmail.com"
      type="cite">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>
    </blockquote>
    It's the good way.<br>
    <blockquote
cite="mid:CAP2RsaL_-HNhG3dLajFzPGF+5vFPNX7DYwkL89bGBqNZC1xzhg@mail.gmail.com"
      type="cite">
      <div><font><span style="line-height:normal"><span style="">
            </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>
    </blockquote>
    According to PgAdmin III, the GUI interface for PostgreSQL, "DROP
    DATABASE example;" should delete completely the database and all its
    components. The components who are not deleted by this command are
    tablespaces, group roles and user roles, as I see in the left panel
    of PgAdmin III. I don't know about the old geometry_columns table
    who is now a VIEW of a system table hidden inside PostgreSQL since
    PostGIS 2.0. I suppose that the system tables are also deleted by
    DROP DATABASE.<br>
    <br>
    If you plane to use the new features of PostGIS 2.0, run in your
    database the script "topology.sql" for topology functions and
    "rtpostgis.sql" for raster image functions after the restoration. <br>
    <br>
    <blockquote
cite="mid:CAP2RsaL_-HNhG3dLajFzPGF+5vFPNX7DYwkL89bGBqNZC1xzhg@mail.gmail.com"
      type="cite">
      <div><font><span style="line-height:normal"><span style="">
            </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>
      </div>
    </blockquote>
    Regards.<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 moz-do-not-send="true" href="javascript:_e({}, 'cvml',
      'sracine@igreffe.net');" target="_blank">sracine@igreffe.net</a><br>
    Site: <a moz-do-not-send="true" href="http://www.igreffe.net"
      target="_blank">http://www.igreffe.net</a> (only in French)<br>
    <br>
    <blockquote
cite="mid:CAP2RsaL_-HNhG3dLajFzPGF+5vFPNX7DYwkL89bGBqNZC1xzhg@mail.gmail.com"
      type="cite">
      <div>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 moz-do-not-send="true"
              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 moz-do-not-send="true" href="javascript:_e({},
              'cvml', 'sracine@igreffe.net');" target="_blank">sracine@igreffe.net</a><br>
            Site: <a moz-do-not-send="true"
              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
                  moz-do-not-send="true"
                  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 moz-do-not-send="true">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>
                  </blockquote>
                </div>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
postgis-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>