Re: seg fault crashed the postmaster

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.

In response to

Responses

Browse pgsql-general by date

  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