From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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-08-05 04:57:49 |
Message-ID: | 14495.1091681869@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-08-05 06:01:06 | Re: [BUGS] casting strings to multidimensional arrays yields strange |
Previous Message | Christopher Kings-Lynne | 2004-08-05 04:37:12 | Re: DROP TABLESPACE causes panic during recovery |