I am not able t install the PostgreSQL 8.3.1 version on windows vista
anyone tried the same? or have any suggestions?
We installed 8.3.1 on a Visa Home Edition laptop. I don't really recall
any issue. What happened to you? I know Vista prompts for all sorts of
things that you'll have to
Without worrying about debugging your script, have you considered using
pg_standby that's in contrib? It works well and you don't have to fuss
with scripts unless you're doing something special.
David
---(end of broadcast)---
TIP 9: In versions
Brian Modra wrote:
Sorry to be hammering this point, but I want to be totally sure its
OK, rather than 5 months down the line attempt to recover, and it fails...
Are you absolutely certain that the tar backup of the file that
changed, is OK? (And that even if that file is huge, tar has
When running WAL backups and warm-standby restores (we're currently on
PG 8.2), do the vacuumlo changes, vacuum, analyze and reindex type
commands get pushed through WAL files to the backup? Or will the backup
database not have these maintenance items done?
Thanks,
David
If there are no other tables storing large objects in the database,
dropping and reloading the whole database is probably the simplest
solution. Otherwise they're going to need to make sure the unwanted
LOs have been cleaned out (see contrib/vacuumlo) and then do a VACUUM
FULL or similar on
LOG: database system was shut down at 2008-01-11 11:40:05 PST
LOG: starting archive recovery
LOG: restore_command = ~/postgresql/bin/pg_standby -l -d -s 2 -k 20
-t ~/postgresql/restoreWALs/STOP_RESTORE ~/postgresql/restoreWALs %f
%p 2 ~/pg_standby.log
*LOG: restored log file
No. Once you've done any transactions in the backup DB, its transaction
history has diverged from the master and you can't resume tracking the
master. It shouldn't even let you try --- what shenanigans did you pull
to force it back into recovery mode?
Well, I didn't think it was
Using PG 8.2, I have a database in recovery mode using pg_standby to
handle the WAL restores.
Is it allowable to have a backup database in recovery mode, then stop
recovery (in this case, by putting the trigger file in place to stop
pg_standby), check out that the backup db appears up to
I'm trying to get WAL file copying working across two systems. It seems
pretty straightforward to handle this in the archive_command of the
primary, in which I am able to copy the files easily to a staging area
for the backup system.
On the backup system, I have the recovery.conf pointing to
I'm using cygwin on WinXP and upgrading from 8.1 to 8.2.4.
Under 8.1, I ran a full backup and stored that as GZIP file.
Under 8.2, I tried to restore using the command:
gunzip -c backup81.gz | pg_restore -v -O -d mydb
This returned an error: pg_restore: [archiver] did not find magic
string
wrote:
On Tue, Aug 21, 2007 at 7:23 PM, in message [EMAIL PROTECTED],
David Wall [EMAIL PROTECTED] wrote:
I'm using cygwin on WinXP
gunzip -c backup81.gz | pg_restore -v -O -d mydb
This returned an error: pg_restore: [archiver] did not find magic
string in file header
Out
I've created several blobs using the OID type. I note that the database
stores the "oid" number that represents two files on disk, such as xinv21281
and xinx21281 with the oid in the database showing up as 21281 via a SELECT.
But, I deleted a row that contained this oid, and the two 'x' files
12 matches
Mail list logo
