Port Bug Report: transaction control interacts strangely with drop table - Mailing list pgsql-ports

From Unprivileged user
Subject Port Bug Report: transaction control interacts strangely with drop table
Date
Msg-id 199906170211.WAA53662@hub.org
Whole thread Raw
Responses Re: [PORTS] Port Bug Report: transaction control interacts strangely with drop table
Re: [PORTS] Port Bug Report: transaction control interacts strangely with drop table
List pgsql-ports
============================================================================
                        POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name               : Christopher Oliver
Your email address      : oliver@traverse.net

Category                : runtime: back-end
Severity                : serious

Summary: transaction control interacts strangely with drop table

System Configuration
--------------------
  Operating System   : Linux 2.0.33 ELF

  PostgreSQL version : 6.5

  Compiler used      : 2.7.3.2

Hardware:
---------
Pentium 133 / 64M RAM

Versions of other tools:
------------------------


--------------------------------------------------------------------------

Problem Description:
--------------------
Transactions do not protect against outside visibility of
drop table.  The interaction leaves an empty file which
held the table which prevents a similarly named table
from being created.  Further aborting does not undo
effects of drop table.  This does not seem right.



--------------------------------------------------------------------------

Test Case:
----------
Scenario:

  1) open two psql sessions (A and B) on the same database.

  2) in session 1, create a talbe an populate with entries.

  3) in session 2, select * from table to see that values
  are present;

  4) in session 1, begin a transaction and drop the
  newly created table.

  5) in session 2, select * from the table.  Observe
  that the entries are gone though the transaction is
  not commited.

  6) In session 1, commit the transaction.

  7) In session 2, observe select * still shows an
  empty table where none should exist.

  8) In session 2, observe that while the table doesn't
  exist, you may not create another with the same name.
  (The file representing the table still exists, and it
  is empty.)

Note also that an abort of the transaction will not cause
the data to return.


--------------------------------------------------------------------------

Solution:
---------


--------------------------------------------------------------------------


pgsql-ports by date:

Previous
From: Keizo Shimizu
Date:
Subject: 6.5 make error on Solaris 2.5.1
Next
From: Bruce Momjian
Date:
Subject: Re: [PORTS] Port Bug Report: transaction control interacts strangely with drop table