Re: ERROR: type "temp_gc" already exists

From: Janning Vygen <vygen(at)gmx(dot)de>
To: pgsql-general(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Damon Hart <dhcom(at)sundial(dot)com>
Subject: Re: ERROR: type "temp_gc" already exists
Date: 2005-10-18 07:45:06
Message-ID: 200510180945.06689.vygen@gmx.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I tried to reproduce it, but it seems that my problem vanished since i
switched from pg_pconnect to pg_connect in PHP. Maybe this is of any help.
But in my understanding the reported failure should not be influenced by
selection of pg_connect vs. pg_pconnect.

i will report if this problem arises again.

kind regards,
janning

Am Mittwoch, 28. September 2005 16:07 schrieb Tom Lane:
> Janning Vygen <vygen(at)gmx(dot)de> writes:
> > I recently reported this problem and i would like to help solving it. But
> > how can i build a self-contained test-case? It just happens sometimes
> > under load.
>
> I didn't say you need to make it 100% reproducible; you just have to
> make a case that someone else can run that will eventually produce the
> error. The sort of poking and prying that will need to happen to debug
> it will involve things you do not want done to your production database,
> therefore we need to be able to make the error happen in a test setup.
>
> You probably need to create a client script that will issue multiple
> parallel queries that are similar to what your regular application does.
> See for instance this discussion:
> http://archives.postgresql.org/pgsql-hackers/2005-05/msg00613.php
> If you're handy with C, pgbench might be a useful starting point.
> But a script in perl python or tcl will be fine too.
>
> regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Teodor Sigaev 2005-10-18 08:09:13 Re: re : tsearch2 problem
Previous Message Devrim GUNDUZ 2005-10-18 06:34:58 Re: PG 8.0.4, Centos and 64 bit