Re: [HACKERS] Table drop that fails ... "No such file or directory"

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