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

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.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@tpf.co.jp