Crash Recovery, pt 2

On Fri, 2003-01-24 at 07:22, Andrew Sullivan wrote:
> On Thu, Jan 23, 2003 at 10:32:58PM -0500, Noah Silverman wrote:
> > To preface my question, we are still in the process of evaluating postgres
> > to determine if we want to switch our production environment over.
> >
> > I'm curious about where I can find documentation about crash recovery in
> > postgres. In mysql, there is a nice table recovery utility (myisamchk).
>
> It recovers automatically. Make sure you run with fsync turned on.
> That calls fsync on the WAL at the point of every COMMIT, and COMMIT
> isn't finished before the fsync returns. Then, in case of a crash,
> the WAL just plays back and fixes up the data area.

On commercial databases, there's a command to flush the roll-forward
logs to tape at intervals during the day.

Thus, if the disk(s) get corrupted, one can restore the database to
new disks, then apply the on-tape roll-forward logs to the database,
and you'd have only lost a few hours of data, instead of however
many hours (or days) it's been since the last database backup.

Also, flushing them to tape (or a different partition) ensures that
they don't fill up the partition during a particularly intensive
batch job.

Are there any FM's that explain how this works in Postgres?

Thanks,
Ron
--
+---------------------------------------------------------------+
| Ron Johnson, Jr. mailto:ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "Fear the Penguin!!" |
+---------------------------------------------------------------+