On Fri, 7 Jan 2000, Bruce Momjian wrote:
> > 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.
Hmmm...problem is, I would think, in most cases it wouldn't be noticed
until a later time, this case as an example...
> > 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.
Or it could be nothing more then a hard crash of the server :(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org