Re: [BUGS] BUG #5412: test case produced, possible race condition.
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #5412: test case produced, possible race condition. |
Дата | |
Msg-id | 10850.1271273410@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #5412: test case produced, possible race condition. (Rusty Conover <rconover@infogears.com>) |
Ответы |
Re: [BUGS] BUG #5412: test case produced, possible race condition.
|
Список | pgsql-hackers |
Rusty Conover <rconover@infogears.com> writes: > On Apr 14, 2010, at 2:31 PM, Tom Lane wrote: >> There is another slightly odd thing here, which is that the stack trace >> Rusty provided clearly shows the crash occurring during processing of a >> local relcache invalidation message for the truncated relation. > The test case program was the smallest thing I could write to reproduce the problem consistently on my machine, but I couldn'treproduce it consistently on other machines and architectures. I'm glad Heikki was able to also see the crash onhis hardware. I can take Heikki's patch back out and get a new stack trace from the test program if that would be usefulto you. Yeah, I'm curious to know if the stack trace is the same for crashes in the watered-down test case. AFAICS, relcache invals triggered by the TRUNCATE itself ought to be serviced before we get out of the TRUNCATE; and after that, the xact is holding exclusive lock on the table so there's no way that we should get a remote inval on the specific relation (not to mention that the trace is clearly about a local inval not an incoming remote inval). So I don't understand why the trace says that it's happening during a subsequent INSERT. Mind you, Heikki's patch looks like a good idea in any case; but I'm not sure that there isn't something else going on here. regards, tom lane
В списке pgsql-hackers по дате отправления: