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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Patch for disaster recovery
Date: 2005-02-20 14:45:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)org> writes:
> > Hmmm...after seeing Tom's reply, I suppose I should have first
> > asked, "Gee, looks simple, but does it work?"  Should I even bother
> > experimenting with it in a test environment?
> Experiment away, but I have a hard time visualizing how you'll find it
> useful.
> Just brainstorming here, but it seems to me that what might make some
> kind of sense is a command to "undelete all tuples in this table".
> You do that, you look through them, you delete the versions you don't
> want, you're happy.  The problem with the patch as-is is that (a)
> "deleting the versions you don't want" is a no-op, so you cannot keep
> straight what you've done in terms of filtering out garbage; and (b)
> when you revert to a non-broken postmaster, the stuff you couldn't see
> before goes back to being unseeable, because after all you didn't change
> its state.

It would be used only for dumping the table out and reverting to the
regular postmaster.

> With either the snapshot kluge or the undelete-all kluge, you have an
> issue in that constraints are broken wholesale --- you can see lots of
> duplicate row versions that violate unique constraints, deleted versions
> that violate FK constraints because they reference also-deleted master
> rows, deleted versions that violate later-added CHECK constraints, etc.
> I'd sort of like to see the system flip into some mode that says "we're
> not promising constraints are honored", and then you can't go back to
> normal operation without going through some pushup that checks all the
> remaining rows satisfy the declared constraints.
> In any case I suspect it's a bad idea to treat tuples as good if their
> originating transaction did not commit.  For starters, such a tuple
> might not possess all the index entries it should (if the originating
> transaction failed before inserting said entries).  I think what we
> want to think about is overriding delete commands, not overriding
> insert failures.
> Not sure where this leads to, but it's not leading to an undocumented
> one-line hack in tqual.c, and definitely not *that* one-line hack.

Yea, it should be more precise about showing only delete stuff and not
uncommitted creates.  Let me work on that.

  Bruce Momjian                        |
  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

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-02-20 14:58:32
Subject: Re: Patch for disaster recovery
Previous:From: Bruce MomjianDate: 2005-02-20 14:43:11
Subject: Re: Patch for disaster recovery

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