I am trying to learn/practice the administrative steps that would need
to be taken in a 'fat finger' scenario, and I am running into problems.
I am trying to use 'recovery.conf' to set the database state to about 15
minutes ago in order to recover from accidentally deleting important
data. Howe
Some more bits on this:
And playing with the date format does not seem to change the outcome
(the db is always recovered to the most current state). In this case, I
removed the timezone designation 'PDT' from my timestamp, and the db
properly figured out that it is running in GMT-7 (pacific) t
"Jason L. Buberel" <[EMAIL PROTECTED]> writes:
> What worries me is the 'record with zero length',
That's just the normal way of detecting end of WAL.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the pos
I now have a working xlogdump, which has allowed me to put together the
following steps which I believe demonstrate that the recovery process
insists on recovering to the most recent state.
Here is the sequence of events shown below:
1. Display contents of 'account_note' table
2. Update note f
Minor correction to the output below - the final table dump actually
contained the following - my apologies for the copy/paste error:
altos_research=# select * from account_note;
account_note_id | customer_account_id | user_id_of_author |
creation_date | note
-+---
"Jason L. Buberel" <[EMAIL PROTECTED]> writes:
> ## stopped and started postgres, following syslog output:
You seem to have omitted all the interesting details about what you did
here; but "stopping and starting" postgres is certainly not intended to
cause it to discard data. There would need to
I am now learning that fact, but recall the original scenario that I am
trying to mimic:
1. Person accidentally deletes contents of important table.
2. Admin (me) wants to roll back db state to just prior to that deletion.
3. (Me) Assumes that by creating a recovery.conf file and setting the
ta
I think that I now see the error of my ways.
When I shutdown my server, the files under the ./data/ directory still
all point to 'now' and not 'a week ago when the backups were taken'. So
the recover process insists on bringing the database to a PITR equal to
'now'.
Instead, in order to achi
"Jason L. Buberel" <[EMAIL PROTECTED]> writes:
> Instead, in order to achieve my goal I would have to restore to that
> backup, and rely on the contents of the archive_logs to have the
> recovery process return me to the selected xid PITR.
Correct.
> So is there any way to 'trick' or force the
On Jul 2, 2007, at 11:58 PM, Jason L. Buberel wrote:
I am now learning that fact, but recall the original scenario that
I am trying to mimic:
1. Person accidentally deletes contents of important table.
2. Admin (me) wants to roll back db state to just prior to that
deletion.
3. (Me) Assumes
Understood all around - thanks to everyone for helping me clarify (in my
head/understanding) how these pieces fit together.
One last request - can you glance over the plan below and let me know if
it sounds sane? The goal again is to be able to recover to a PITR record
in the very recent past
11 matches
Mail list logo
