Re: Error from index "pg_type_typname_index"????

From: fabrizio(dot)ermini(at)sysdat(dot)it
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Error from index "pg_type_typname_index"????
Date: 2001-02-12 15:55:07
Message-ID: 3A88156B.1489.1B75F3C@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 12 Feb 2001, at 10:10, Tom Lane wrote:

> > ERROR: Cannot insert a duplicate key into unique index
> > pg_type_typname_index
> > The query causing it it's an innocent query that duplicates a table
> > in a temporary one, i.e.
> > "select * into forum_clone from forums"
>
> I think you're probably trying to do two of these at the same time.
>
And you do think right. (And this should not came as a surprise, I
would add :-)).
I've ascertained it doing a little stress-testing, and simply rethinking
on the fact that I was doing a dumb thing...

> I'll take a look to see if the order of operations can't be reversed so
> that you get a more understandable complaint about a unique index on
> pg_class in this case. However, the real answer for you is to be using
> a TEMP table if you are going to have multiple clients creating
> temporary tables at about the same time. That avoids the name conflict.
>

Nope. This is the first thing I've tried after I've realized what was
happening, but it does not work in a web environment, at least in a
PHP based like mine; I think it scales down to PHP ways of
optimizing connection pool (which, in effect, have given me some
worry over time): if use a TEMP table and try to stress test the
page (i.e. "hit furiosly F5 cycling to several explorer windows with
the mouse" :-)) i got many errors complaining things such "table
doesn't exist" or similar. Evidently the various TEMP tables of the
various pages where mismatching, since they have a lifetime based
on the concept of a "session" that's not 1:1 with the lifetime of a
web page.

I resorted to handle the creation of the various tables at application
level, creating temp tablenames with uniqueid() function. A little
overhead but it works well.

Summarizing all this thoughts, the moral is that it's not been PG's
fault (unless for a less-than-clear error message, but that's a venial
sin :-)), that I should think more before screaming wolf, and that I
really should study better the way PHP handles PG connection...
there's some "hidden magic" in there that doesn't convince me.

Thanks for you attention, as ever, and
Ciao

Fabrizio

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Fabrizio Ermini Alternate E-mail:
C.so Umberto, 7 faermini(at)tin(dot)it
loc. Meleto Valdarno Mail on GSM: (keep it short!)
52020 Cavriglia (AR) faermini(at)sms(dot)tin(dot)it

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2001-02-12 16:04:55 Re: strange query results
Previous Message Mark 2001-02-12 15:39:24 jdbc fastpath error & Z error (URGENT NEED!!!)