Re: Backup Question

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

In response to

Responses

Browse pgsql-general by date

  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