Shaun Thomas wrote:
Wrong. The database cannot check all data for consistency
upon backup. For one, that would take way too long.
Well, what I meant, was that it would stop the database if it couldn't
apply one of the transaction logs for whatever reason. It wasn't
inconsistent enough for
On Tue, Oct 22, 2013 at 1:10 PM, Shaun Thomas stho...@optionshouse.comwrote:
So you can grab the extra files, but you can't make it apply them,
as you are telling it that it doesn't need to.
Do I have to, though? Replaying transaction logs is baked into the crash
recovery system. If I
Hey everyone,
This should be pretty straight-forward, but figured I'd pass it by anyway.
I have a revised backup process that's coming out inconsistent, and I'm not
entirely sure why. I call pg_start_backup(), tar.gz the contents elsewhere,
then pg_stop_backup(). Nothing crazy. Upon restore,
Shaun Thomas wrote:
I have a revised backup process that's coming out inconsistent, and I'm not
entirely sure why. I call
pg_start_backup(), tar.gz the contents elsewhere, then pg_stop_backup().
Nothing crazy. Upon restore,
two of my tables report duplicate IDs upon executing my redaction
Wrong. The database cannot check all data for consistency
upon backup. For one, that would take way too long.
Well, what I meant, was that it would stop the database if it couldn't
apply one of the transaction logs for whatever reason. It wasn't
inconsistent enough for that. :)
If you
On Tue, Oct 22, 2013 at 6:47 AM, Shaun Thomas stho...@optionshouse.comwrote:
Hey everyone,
This should be pretty straight-forward, but figured I'd pass it by anyway.
I have a revised backup process that's coming out inconsistent, and I'm
not entirely sure why. I call pg_start_backup(),
So you can grab the extra files, but you can't make it apply them,
as you are telling it that it doesn't need to.
Do I have to, though? Replaying transaction logs is baked into the crash
recovery system. If I interrupt it in the middle of a checkpoint, it should be
able to revert to the
