Re: [HACKERS] Dropping tables...

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at>, "'hackers(at)postgresql(dot)org'" <hackers(at)postgreSQL(dot)org>, "Dr(dot) Michael Meskes" <meskes(at)online-club(dot)de>
Subject: Re: [HACKERS] Dropping tables...
Date: 1998-08-01 10:06:55
Message-ID: 35C2E8BF.C0CD9F6C@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vadim Mikheev wrote:
>
> Andreas Zeugswetter wrote:
> >
> > I would say allow the drop table, of course only if no update or
> > intent update (select for update) lock is on it.
> > This is how Informix behaves. Otherwise it will become very
> > hard to drop tables altogether.
>
> Ok, currently, table can't be dropped if SELECTed by another
> running transaction.
>
> Would we like to change this ?!

Due to the lack of shared catalog cache I would like to
preserve current behaviour:

System catalogs are scanned by transaction once on first open
of relation and so there is no way for trasnaction to know if
relation was dropped by another backend. If relation file
will not be closed by Virtual file descriptor code (fd.c)
then subsequent operations over relation will be ok
else -> elog(ERROR, "cannot open _relation_") from smgr.c
or even worse if relation will be re-created in the meantime...

We wouldn't like these unpredictable results, yes ?

Vadim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-01 10:55:16 OR clause - check code
Previous Message David Hartwig 1998-08-01 09:19:43 6.4 Aggregate Bug