The good news: after much pain, I was able to develop a semi-repeatable
test for that duplicate-tuple problem. (It's a script of about 6300 SQL
commands for five concurrent backends, which takes about 10 minutes to
run and produces a corrupted table about one run out of two...) And
this test indicates that the current CVS sources don't have the bug.
So, rather than expending a lot of effort trying to figure out just
what the bug is in 6.3.2, we are going to cross our fingers and put our
production application on 6.4beta.
The bad news: this same script exposes a different bug in the current
sources (and perhaps older releases too). *Very* rarely, like less
than one run out of ten, the test driver gets wedged or fails with an
"out of memory" error. I just traced this to its cause, and the cause
is that a SELECT reply coming from the backend is corrupt. In fact,
what I see in libpq's input buffer is that a "NOTIFY" message has been
inserted into the middle of the tuple data :-(. So the interlock that
supposedly prevents Async_NotifyFrontEnd() from being invoked during
another command does not work reliably.
I will look into this, but I could use advice from anyone who
understands how that stuff is supposed to work.
regards, tom lane