Thread: Wierd error when creating a table...

When I try to create a table where the primary key is set to be a column
that is of type int8 or int28 it complains giving me the following
error:

ERROR:  Can't find a default operator class for type 22.

If I try to define the table again, it tells me that the relation
already exists, yet it doesnt who up on the table list when I hit \d in
psql.

I also get the error if I try to define an index based on a field with
one of those types.

Is this a known bug, or am I trying to do something odd?

TIA

Alex T

Alex Turner <aturner@maaco.com> writes:
> When I try to create a table where the primary key is set to be a column
> that is of type int8 or int28 it complains giving me the following
> error:

> ERROR:  Can't find a default operator class for type 22.

Postgres 6.4 doesn't have support for indexes on int8 fields (but 6.5
does).  There is no support for indexes on int28 in either release.

> If I try to define the table again, it tells me that the relation
> already exists, yet it doesnt who up on the table list when I hit \d in
> psql.

That's a bug: the physical file for the relation has already been
created by the time the failure in creating the index occurs, and
although all the updates to system tables get backed out, the empty
file is not removed during the transaction abort.  So the table is
not there as far as any subsequent SQL commands are concerned, but
CREATE TABLE is (very properly IMHO) unwilling to overwrite any
random file it finds in the database directory.

You can reach into the data/base/YOURDB/ directory and delete the file
by hand.

I believe fixing this is on the TODO list, but I see that the bug is
still there in 6.5-current.  Something we might be able to squeeze in
for 6.5 is a more helpful error message ("I don't want to overwrite
file thus-and-so, delete it by hand if you are sure it's OK...").
        regards, tom lane

I wrote:
> That's a bug: the physical file for the relation has already been
> created by the time the failure in creating the index occurs, and
> although all the updates to system tables get backed out, the empty
> file is not removed during the transaction abort.

After further investigation, the above is wrong, or at least obsolete:
the physical file for the table that couldn't be created *is* removed
when the transaction is cleaned up.  (At least it is in current 6.5
code; didn't try older versions.)  There's still a bug though ---
apparently the system still has an entry for the failed table in its
"relation cache", and that prevents a subsequent CREATE TABLE for the
same table name from succeeding.

A workaround is to exit your psql session and start a new one; the
new backend won't have the erroneous cache entry.  This needs to be
fixed though.
        regards, tom lane