Re: [HACKERS] Dropping tables... - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] Dropping tables...
Date
Msg-id 35C2E8BF.C0CD9F6C@krs.ru
Whole thread Raw
In response to ...  (Andreas Zeugswetter <andreas.zeugswetter@telecom.at>)
List 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

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: AW: [HACKERS] OR clause status report
Next
From: Bruce Momjian
Date:
Subject: OR clause - check code