From: | Gordon Shannon <gordo169(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: seg fault crashed the postmaster |
Date: | 2010-12-31 17:31:34 |
Message-ID: | AANLkTik-YyxHu8d_VwBu8bjuWB6NqOKOvGXYrNaZdQoS@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Interesting. That's exactly what we have been doing -- trying to update the
same rows in multiple txns. For us to proceed in production, I will take
steps to ensure we stop doing that, as it's just an app bug really.
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] <
ml-node+3323712-1368244686-56124(at)n5(dot)nabble(dot)com<ml-node%2B3323712-1368244686-56124(at)n5(dot)nabble(dot)com>
> 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: http://postgresql.1045698.n5.nabble.com/seg-fault-crashed-the-postmaster-tp3323117p3323796.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Gordon Shannon | 2010-12-31 17:52:19 | Re: seg fault crashed the postmaster |
Previous Message | Håvard Wahl Kongsgård | 2010-12-31 17:06:19 | Overriding default psql behavior | how to ignore missing fields |