From: Simon Riggs <simon@2ndquadrant.com>
To: Brendan Duddridge <brendan@clickspace.com>
Cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Recovery will take 10 hours
Date: Mon, 24 Apr 2006 18:27:31 +0100
Message-ID: <1145899652.3112.326.camel@localhost.localdomain> (raw)
In-Reply-To: <F823FC8E-70C4-41D0-A812-F2C7E2ECFF1E@clickspace.com>
References: <85A15B2E-F59C-4FEF-82D4-61F48ABDCDE5@clickspace.com>
<1145808368.3112.222.camel@localhost.localdomain>
<F823FC8E-70C4-41D0-A812-F2C7E2ECFF1E@clickspace.com>
On Sun, 2006-04-23 at 22:46 -0600, Brendan Duddridge wrote:
> So how do you overlap the restore process with the retrieving of files?
The restore command can be *anything*. You just write a script...
> Our restore command is:
>
> restore_command = 'gunzip </wal_archive/%f.gz>%p'
>
> If I change it to:
>
> restore_command = 'gunzip </wal_archive/%f.gz>%p &'
>
> to execute the restore command in the background, will that do the
> trick?
No, but you can execute a shell script that does use & internally.
> But I don't think the real problem was the retrieval of the files. It
> only
> took maybe 1/2 a second to retrieve the file, but often took anywhere
> from
> 5 to 30 seconds to process the file. More so on the longer end of the
> scale.
Sorry, thought you meant the decompression time.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: simon@2ndquadrant.com, brendan@clickspace.com
Subject: Re: Recovery will take 10 hours
In-Reply-To: <1145899652.3112.326.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox