The table in question -- v_messages -- is an empty base table with 76 partitions, with a total of 2.8 billion rows.
Let me summarize what I see as the key facts here:
(All problems have come from the UPDATE query, all identical except for different "author_id" values.)
1. We did a "link" upgrade Wed night, from 844 to 902 so the upgrade happened in place, no data files were copied.Â
2. The 1st error was "compressed data is corrupt" at 18:16
3. We got 2 seg fault crashes before turning on cores and getting a 3rd crash with the stack trace.
4. We then got a " invalid memory alloc request size 18446744073449177092" at 23:50. This was an ERROR, not a crash.
At this point, is it your suspicion that there is a code bug in 9.0.2, rather than corrupt data?
I will post the schema and then work on a test case.
-gordon
On Fri, Dec 31, 2010 at 8:34 AM, Tom Lane-2 [via PostgreSQL] <[hidden email]> wrote:
Hmm. ÂThis suggests that there's something wrong in the EvalPlanQual
code, which gets invoked when there are concurrent updates to the same
row (ie, the row this UPDATE is trying to change is one that was changed
by some other transaction since the query started). ÂThat stuff got
rewritten rather thoroughly for 9.0, so the idea of a new bug there
isn't exactly surprising. ÂBut it's going to be hard to find without
a test case. ÂCan you show us the full schema for this table and all
the queries that execute against it up till the point of the failure?
(Turning on log_statement across all sessions would help collect that
info, if you don't have it already.)
View this message in context: Re: seg fault crashed the postmaster
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
