| 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: | Whole Thread | Raw Message | 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 |