Skip site navigation (1) Skip section navigation (2)

RE: [HACKERS] DROP TABLE inside a transaction block

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Mike Mascari" <mascarm(at)mascari(dot)com>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Philip Warner" <pjw(at)rhyme(dot)com(dot)au>, "Lamar Owen" <lamar(dot)owen(at)wgcr(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Tatsuo Ishii" <t-ishii(at)sra(dot)co(dot)jp>, <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-08 09:40:20
Message-ID: 000a01bf88e2$5193f260$2801007e@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Mike Mascari
> 
> Can I throw one more question out there on this subject?
> 
> There's something that I view as inconsistent behavior with
> respect to DDL statements and MVCC and was wondering if this
> would have any impact on the discussion (the following is with
> 6.5.3):
> 
> Session #1:
> 
> emptoris=> begin;
> BEGIN
> emptoris=> select * from test;
> value
> -----
>     1
> (1 row)
> 
> Session #2:
> 
> emptoris=> begin;
> BEGIN
> emptoris=> select * from test;
> value
> -----
>     1
> (1 row)
> 
> Session #1:
> 
> emptoris=> drop table test;
> DROP
> 
> Session #2:
> 
> emptoris=> select * from test;
> ERROR:  mdopen: couldn't open test: No such file or directory
> 
> Now it would seem to me that if DROP TABLE is going to be
> ROLLBACK-able, then Session #2, in a MVCC environment should
> never see:
> 
> ERROR:  mdopen: couldn't open test: No such file or directory
> 
> but it does, because the "effect" of the drop table is an action
> that is seen by all sessions, as though it were "committed".

The inconsistency is due the current implementation of DROP
TABLE which immediately unlinks the base relation file phisically.
Though the definition(i.e pg_class tuple) of test relation still exits
(logically),the base relation file doesn't exist.
 
PostgreSQL has a standard mechanism of transaction control
for tuples but there's no such mechanism for relation files.
Currently even a single DDL command outside transaction
doesn't have atomicity. I have really disliked this feature(? bug)
for a long time.
Flexible mapping from a relation to the relation file name is
needed in order to enable transaction control for relation files. 

Regards.

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

In response to

pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2000-03-08 10:12:43
Subject: RE: [HACKERS] DROP TABLE inside a transaction block
Previous:From: Tom LaneDate: 2000-03-08 08:41:17
Subject: Re: [HACKERS] DROP TABLE inside a transaction block

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group