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
On Tue, Mar 14, 2006 at 02:12:39PM -0500, Jonah H. Harris wrote:
> On 3/14/06, Jim C. Nasby <[EMAIL PROTECTED]> 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/relo
On 3/14/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
Setting up Slony might be another option; you'd essentially be followingthe procedure used to speed up a PostgreSQL upgrade that would normallyrequire a dump/reload.
If you need to do this on a continuing basis, Slony is the best way to
go. If it
On Mon, Mar 13, 2006 at 01:36:28PM -0500, Jonah H. Harris wrote:
> What could be done in order to fix it? Is there any kind of application to
> > translate it or the only solution was to "pg_dumpall" and "pg_restore" the
> > cluster?
> >
>
> Yes, dump and restore is the best way to go.
Setting up
"Rodrigo Hjort" <[EMAIL PROTECTED]> writes:
> What could be done in order to fix it? Is there any kind of application to
> translate it or the only solution was to "pg_dumpall" and "pg_restore" the
> cluster?
Unfortunately pg_dump/pg_restore is going to be your only option here. The
database fil
On 3/13/06, Rodrigo Hjort <[EMAIL PROTECTED]> wrote:
As
the architecture on both Linuxes are different (32 and 64 bits), I
think "PGDATA/global/pg_control" might contains 64 bit data such that
the 32 bits binary won't recognize or even mispell it. Am I right?
Yes, the platform architecture is key.
On Mon, Mar 13, 2006 at 02:56:00PM -0300, Rodrigo Hjort wrote:
> Dear PostgreSQL Hackers,
>
> We got a PG 8.1 on a Debian 64 bits, which does a full backup (PITR) daily.
> Then we installed a Debian 32 bits (actually, it's on VMWare) and wanted to
> restore the previous PG cluster on it.
> As ther
Dear PostgreSQL Hackers,We got a PG 8.1 on a Debian 64 bits, which does a full backup (PITR) daily.Then we installed a Debian 32 bits (actually, it's on VMWare) and wanted to restore the previous PG cluster on it.
As there are a lot of indexes, specially GiST, "pg_dump" and "pg_restore" are not via
