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

Re: [PORTS] Port Bug Report: transaction control interacts strangely with drop table

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Christopher Oliver <oliver(at)traverse(dot)net>
Cc: pgsql-ports(at)postgreSQL(dot)org
Subject: Re: [PORTS] Port Bug Report: transaction control interacts strangely with drop table
Date: 1999-09-28 19:56:02
Message-ID: 199909281956.PAA26904@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-ports
We are working on cleaning this up for 6.6.  We will issue notices to
the user so they know they can't rollback a transaction that deletes a
table.



> 
> ============================================================================
>                         POSTGRESQL BUG REPORT TEMPLATE
> ============================================================================
> 
> 
> Your name               : Christopher Oliver
> Your email address      : oliver(at)traverse(dot)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:
> ---------
> 
> 
> --------------------------------------------------------------------------
> 
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-ports by date

Next:From: jefpaiDate: 1999-09-29 16:28:22
Subject: pgtclsh.exe
Previous:From: Jonathan WilcoxDate: 1999-09-28 19:47:32
Subject: installation report - Redhat Linux 6.0

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