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
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 Slony might
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's
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/reload.
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 viable
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 there are
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.
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 files are
