Re: Restarting DB after moving to another drive

From: Daniel Begin <jfd553(at)hotmail(dot)com>
To: "'Francisco Olarte'" <folarte(at)peoplecall(dot)com>
Cc: <rod(at)iol(dot)ie>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Restarting DB after moving to another drive
Date: 2015-05-15 15:35:47
Message-ID: COL129-DS15F7A76BA197E7E4DA24BF94C70@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bonjour Francisco.

Skimming the documentation sequentially is a cleaver advice, especially since the doc is much of the time well done and exhaustive. Unfortunately, even if I actually did it about 1 year ago, it seems this specific item slipped out of my mind :-(

About dump/restore operation, restoring the database cluster is running for 24hrs now (psql -f pgdumpallOutputfile postgres). Since it took 13hrs to dump the cluster, I begin to wonder how long it is going to take to restore it...

My main concern is about how the indexes are managed in dump/restore operations. I understand that pg_dumpall actually uses pg_dump where the doc says "Post-data items include definitions of indexes, triggers..." I would not worry if the doc said that indexes are simply copied but it says "includes definition of indexes".

Since some of the indexes took days to build... does someone could confirm indexes are rebuilt instead of copied?
If indexes are actually rebuilt, why should it be done that way? - There must be good reason!

Best regards,
Daniel

-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Francisco Olarte
Sent: May-15-15 05:12
To: Daniel Begin
Cc: rod(at)iol(dot)ie; pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Restarting DB after moving to another drive

Hi Daniel:

On Wed, May 13, 2015 at 8:06 PM, Daniel Begin <jfd553(at)hotmail(dot)com> wrote:
...
> - I still have a lot to learn on database management (it was simpler
> on user's side!-)

Yep, we all do, even if we've been using it since it was called Postgres.

> Fortunately, I have found that pg_dumpall could do the job (I did not have a problem with it, I just did not know about it!-).

If you didn't know about it I'll urge you to take the manual and do a sequential reading ( maybe not in full, this would take a long time, but at least skim through all of it sequentially, it's full of very interesting info and it's very useful and when you hit a problem you'll probably know there is something for it and search for it ).
For me the manual is one of the major points for using pg . pg_dumpall is a fundamental tool for backups, as it's the only one that dumps the global objects.

Good luck.

Francisco Olarte.

--
Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Contraveos 2015-05-15 15:51:32 Nested fields with Mongo FDW
Previous Message Job 2015-05-15 15:34:00 R: Index on integer or on string field