From: | "Alex Zendel" <alexzendel(at)hotmail(dot)com> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Cc: | alexzendel(at)hotmail(dot)com |
Subject: | question about wal and point in time recovery |
Date: | 2005-04-12 13:47:27 |
Message-ID: | BAY103-F4027A6F1BB965362B34C0FC3330@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
hello all,
i work in an organization that has a handful of people accessing a few ms
access database files. i'm strongly considering porting everything to
postgre (as the backend for access) for a number of obvious reasons, one of
the most prominent ones would be the availability of a back up via the write
ahead log. i've been reading up on the wal and point in time recovery in
the online postgre manual. but i have a question about using it:
is it possible to visually read the entries in the log? is it in binary
format? can the log be modified before recovery occurs. my biggest concern
is that somebody in my org, for example, deletes a field or fudges an update
query that changes a foreign key to a single value - and therefore destroys
table links. so what if this happens and nobody notices it for several
weeks? is it possible to read the log and remove this field delete (i.e.,
remove the 'alter table x drop column y' statement)? or in the update the
scenario, find the statement that reads 'update table x set x.y = "corrupt"'
and then remove it from the log? then can we 'replay' the log and restore
our database, sans the destructive statements?
i am aware of the possibility of data corruption when attempting something
like this, especially when multi-changes transactions were used. i don't
intend to use the wal and pitr in these cases.
.....anything else you feel that i should know about using postgre as a back
end for access?
thanks!
az
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2005-04-12 13:50:27 | Re: Log File Maintainance |
Previous Message | Lic. Guillermo González | 2005-04-12 13:27:31 | upper() with LATIN1 problem |