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@xxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
