Thread: Create table doesn't always respect atomicity of transactions.

Off and on, I've been seeing a situation where the following code:begin;create table foo (name text);abort; leaves a
filecalled "foo" in the database directory and
 
further attempts to create a relation called foo or to select anything from
it all fail.  The database has been left in an inconsistent state.

I filed a bug report on this earlier today as it seemed dead on repeatable.
But then I recompiled with debug symbols to have a go at figuring out what
was up and the problem went away. So I recompiled with full optimization
again and the problem still doesn't occur now. I've been starting over each
time with a fresh database so if it was some property of the database
itself, then that state is lost. But this is not the first time I've seen
this. Has any one else seen such a thing? Its rather troublesome 'cause when
it does happen, the database is somewhat unuseable until I remove the file
in question and I hate going in and removing files that are supposed to be
under Postgres' control...

Glancing at the code, I'm wondering if it is possible for a database to get
stuck in "bootstrap mode." It looks like that would cause problems with
transactions not properly unlink'ing files. Though I haven't scoped out the
details of that...

-Z-

> Off and on, I've been seeing a situation where the following code:
>     begin;
>     create table foo (name text);
>     abort; leaves a file called "foo" in the database directory and
> further attempts to create a relation called foo or to select anything from
> it all fail.  The database has been left in an inconsistent state.
> 
> I filed a bug report on this earlier today as it seemed dead on repeatable.
> But then I recompiled with debug symbols to have a go at figuring out what
> was up and the problem went away. So I recompiled with full optimization
> again and the problem still doesn't occur now. I've been starting over each
> time with a fresh database so if it was some property of the database
> itself, then that state is lost. But this is not the first time I've seen
> this. Has any one else seen such a thing? Its rather troublesome 'cause when
> it does happen, the database is somewhat unuseable until I remove the file
> in question and I hate going in and removing files that are supposed to be
> under Postgres' control...

We fixed this problem in 6.4 or 6.5.  Not sure why it goes away.

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