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

Поиск
Список
Период
Сортировка
От fabrizio.ermini@sysdat.it
Тема Re: Error from index "pg_type_typname_index"????
Дата
Msg-id 3A88156B.1489.1B75F3C@localhost
обсуждение исходный текст
Ответ на Re: Error from index "pg_type_typname_index"????  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@tin.it
loc. Meleto Valdarno          Mail on GSM: (keep it short!)
52020 Cavriglia (AR)          faermini@sms.tin.it

В списке pgsql-general по дате отправления:

Предыдущее
От: Fred Yankowski
Дата:
Сообщение: Re: startup Postgres on NT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: strange query results