From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
---|---|
To: | 'Jeff Janes' <jeff(dot)janes(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Backup Question |
Date: | 2013-10-22 20:10:19 |
Message-ID: | 0683F5F5A5C7FE419A752A034B4A0B9797443ED4@sswchi5pmbx2.peak6.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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 previous checkpoint that did succeed. By including the extra WAL files, it would re-apply them, just like in a crash recovery.
Of course, that only works if I interrupt it by shutting the replica down. By backing up across a checkpoint, I run the risk of a race condition where some files were backed up before the checkpoint, and others afterwards. Which raises the question: isn't that risk the same with a regular backup? The database doesn't just stop checkpointing because a backup is in progress. There must be some internal detail I'm missing.
Either way, I'll add a routine to stall the standby backup until the restartpoint corresponding to the pg_start_backup has been replayed. I'll see if that helps.
Thanks!
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | andy | 2013-10-22 20:13:09 | Re: Monitoring number of backends |
Previous Message | Marc Mamin | 2013-10-22 19:54:23 | Re: Error with "return query" ( "return next" working ) with custom type |