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
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 |