Re: >24 hour restore

From: Andrew Sullivan <andrew(at)libertyrms(dot)info>
To: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: >24 hour restore
Date: 2003-05-28 18:14:03
Message-ID: 20030528181402.GK6637@libertyrms.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, May 28, 2003 at 11:59:49AM -0600, Chad Thompson wrote:

> This was my first thought. After about an hour of running, I stopped the
> process, edited the schema file to remove all the foreign keys and triggers.
> I then started it again. So there SHOULD be no triggers right now.

Hmm.

> UPDATE: I stopped the restore, before it was stopped, top showed postmaster
> using 17% CPU. After stopping I noticed that it DID fill my largest table
> (1.16 M tuples) over night. So I am editing the dump file to continue where
> it left off. ( vi is the only thing that is not choking on the 2.4 gig file)
> That is good news because that means it wont take 7-10 days to import, just
> 1-2.

Sounds like you have an I/O problem.

> As for version (oops) my old version was 7.3.1 and I am moving to 7.3.2

Why don't you just shut down your 7.3.1 postmaster and start 7.3.2?
This requires no initdb. If you're changing machines (ISTR you are),
then copy the tree, assuming the same OS.

> Oh, a bit off topic... I remember that I wanted to move the WAL files off of
> the raid but forgot to do it on start up. Can I do that now that the system
> is setup? Where would I find docs to tell me about that?

Sure. Stop the postmaster, copy the pg_xlog directory to the target
location, then make a soft link. (I usually use cp and move the old
dir out of the way temporarily to start with, just in case.)

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dave Tenny 2003-05-28 18:17:21 Re: IN list processing performance (yet again)
Previous Message Dave Tenny 2003-05-28 18:08:02 Re: IN list processing performance (yet again)