RE: [HACKERS] DROP TABLE inside a transaction block

> -----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