Skip site navigation (1) Skip section navigation (2)

Re: Patch for disaster recovery

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Patch for disaster recovery
Date: 2005-02-20 18:08:14
Message-ID: 200502201808.j1KI8EA26808@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Bruno Wolff III wrote:
> On Sun, Feb 20, 2005 at 09:43:11 -0500,
>   Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> > 
> > We regularly have people on IRC who delete data and then want to recover
> > it.  By having the define it makes it easier for us to help them without
> > them having to add actual C code.
> > 
> > Does that make sense?
> 
> You aren't going to get a consistant snapshot if you get back all of the
> deleted rows. With autovacuum it is going to get harder to do this, because
> accidentally making large changes in a table is going to trigger a vacuum.

Right, but as far as I remember the vacuum isn't going to reuse the
rows.  Rather, it is just going to mark them for later reuse.

> It seems like the right way to do this is a recovery using the PITR
> system and putting effort into making that easier is the way to go.

You are assuming someone is running PITR already, which they might not.

This define is just so we can help folks recover deleted stuff under our
guidance.  Also, I think a general GUC mechanism is too dangerous.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-patches by date

Next:From: Michael FuhrDate: 2005-02-20 18:18:22
Subject: Bibliography updates
Previous:From: Bruno Wolff IIIDate: 2005-02-20 15:25:16
Subject: Re: Patch for disaster recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group