Re: DROP TABLESPACE causes panic during 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: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Andrew Dunstan <andrew(at)dunslane(dot)net>, swm(at)linuxworld(dot)com(dot)au, kevin(at)sysexperts(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DROP TABLESPACE causes panic during recovery
Date: 2004-10-06 17:33:54
Message-ID: 200410061733.i96HXtr01422@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Is this fixed?

---------------------------------------------------------------------------

Tom Lane wrote:
> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> > Maybe we could avoid removing it until the next checkpoint? Or is that
> > not enough. Maybe it could stay there forever :/
>
> Part of the problem here is that this code has to serve several
> purposes. We have different scenarios to worry about:
>
> * crash recovery from the most recent checkpoint
>
> * PITR replay over a long interval (many checkpoints)
>
> * recovery in the face of a partially corrupt filesystem
>
> It's the last one that is mostly bothering me at the moment. I don't
> want us to throw away data simply because the filesystem forgot an
> inode. Yeah, we might not have enough data in the WAL log to completely
> reconstruct a table, but we should push out what we do have, *not* toss
> it into the bit bucket.
>
> In the first case (straight crash recovery) I think it is true that any
> reference to a missing file is a reference to a file that will get
> deleted before recovery finishes. But I don't think that holds for PITR
> (we might be asked to stop short of where the table gets deleted) nor
> for the case where there's been filesystem damage.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

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

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2004-10-06 17:35:43 Re: database constraints
Previous Message Alvaro Herrera 2004-10-06 17:27:26 Re: FunctionCall2 performance