Re: Restoring a Full Cluster on a Different Architecture (32 x 64)

Well, actually we're ain't gonna do this procedure regularly, but just in
case of failure - if it ever happens.
For the moment, I did the dump/restore and it worked, but took almost 1
hour, due to tsearch2 indexes on a table.
Yeah, I thought 64-bit data could be stored on other files than pg_control.
So, there's only one way.

Thanks for helping!

2006/3/14, Jim C. Nasby <jnasby(at)pervasive(dot)com>:
>
> On Tue, Mar 14, 2006 at 02:12:39PM -0500, Jonah H. Harris wrote:
> > On 3/14/06, Jim C. Nasby <jnasby(at)pervasive(dot)com> wrote:
> > >
> > > Setting up Slony might be another option; you'd essentially be
> following
> > > the procedure used to speed up a PostgreSQL upgrade that would
> normally
> > > require a dump/reload.
> >
> >
> > If you need to do this on a continuing basis, Slony is the best way to
> go.
> > If it's a one-time shot, I'd just pipe pg_dump to a psql that's
> connected to
> > PostgreSQL on your 32-bit system.
>
> Well, it's not so much a matter of how often you have to do it, but what
> kind of downtime you can tolerate. Setting up Slony just to move a
> cluster from one machine to another is a good amount of extra work, so
> if you don't have the uptime requirement it probably doesn't make sense.
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>

--
Regards,

Rodrigo Hjort
GTI - Projeto PostgreSQL
CELEPAR - Cia de Informática do Paraná
http://www.pr.gov.br