Rusty Conover <rcono...@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't reproduce it consistently
> on other machines and architectures. I'm glad Heikki was able to also see
> the crash on his hardware. I can take Heikki's patch back out and get a new
> stack trace from the test program if that would be useful to 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
