> On Fri, 7 Jan 2000, Bruce Momjian wrote:
>
> > > But...does it make sense to error-out in this case? The user wants to get
> > > rid of the table, the table is already gone physically, just not
> > > virtually...so why not just get rid of the virtual entries also?
> >
> > It shows something very strange happened to him. We don't want this
> > kind of thing to just happen.
>
> Okay...what should be done? How do you trace something like this back?
That is the big question. We need to hear about these problems, because
the represent something very strange happening. Somehow, the physical
table was deleted, but it still existed in the system tables.
>
> The scenario for this particular table, as it was explained to me, was
> that its the result of a join of two other tables...they find that its
> easier to do teh join into one table periodically and use that for
> selects, then doing SELECT/JOINS on the fly ... my thought was that what
> may have happened is they ran out of disk space on the JOIN, the file was
> removed, but not the traces in the systems files, is this a possibility?
Maybe a SELECT INTO failed. You would think it could delete the entries
too, or at least the transaction that created the table would be marked
as aborted.
Not sure how to debug that one.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026