Did we resolve this? ---------------------------------------------------------------------------
Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
