NOTIFY interlock broken (was Yipes, I'm getting bit by duplicate tuples)
От | Tom Lane |
---|---|
Тема | NOTIFY interlock broken (was Yipes, I'm getting bit by duplicate tuples) |
Дата | |
Msg-id | 2192.906844687@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Yipes, I'm getting bit by duplicate tuples (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] NOTIFY interlock broken (was Yipes, I'm getting bit by duplicate tuples)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: