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

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of The Hermit
> Hacker
>
> 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...
>

Isn't it the result of a DROP TABLE failure ?
mdunlink() removes the base file of a relation immediately and
the file couldn't be rollbacked in case of abort.

I have already made it possible to DROP TABLE even though there
aren't base files of relation/indexes in current tree 2 months ago.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp