From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Kislo <kislo(at)athenium(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Transaction, Rollback and Database Corruption question, |
Date: | 2000-11-22 00:10:19 |
Message-ID: | 5013.974851819@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joe Kislo <kislo(at)athenium(dot)com> writes:
> Well, I never issue a drop table. I issue a CREATE TABLE, I issue some
> inserts.. then I TERMINATE the database connection. Implicit rollback
> should uncreate the table and leave everything consistent.
Oh, wait, you're running 7.0.2 aren't you? Update to 7.0.3, it'll get
better. 7.0.2 forgets to run the transaction-abort cleanup routine if
the client disconnects mid-transaction. The database itself is fine,
but the action of deleting the no-longer-referenced table files doesn't
get done.
> If I terminate a large set of create
> tables and inserts in the middle.. and I try again, I get this error
> spewing from the server:
> FATAL 1: my bits moved right off the end of the world!
> Recreate index pg_attribute_relid_attnam_index.
We've heard sporadic reports of this, but I've never been able to
reproduce it myself. If you can submit a reproducible test script,
it'd be a big help.
> Oh, one more thing. How do I, using SQL, determine if a table exists?
> EG, in Mysql it's something like:
> show tables like 'MyTable';
> In Interbase you select it out of the RDBS$RELATIONS table...
In PG you look for its entry in pg_class. What, you wanted a standard ;-) ?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-11-22 00:16:59 | Re: Core dumps, i.e. how to track down a problem |
Previous Message | Wade D. Oberpriller | 2000-11-21 23:46:42 | Core dumps, i.e. how to track down a problem |