Re: 8.3.0 backend segfaults - Mailing list pgsql-bugs

From Tom Lane
Subject Re: 8.3.0 backend segfaults
Date
Msg-id 13629.1205304280@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.3.0 backend segfaults  ("Alex Hunsaker" <badalex@gmail.com>)
Responses Re: 8.3.0 backend segfaults
List pgsql-bugs
"Alex Hunsaker" <badalex@gmail.com> writes:
> the mean time here is a new backtrace I just got (lord knows how... it
> seems to be as soon as I stop trying to make it crash and look away,
> thats when it does).

Not sure that you are clear on what's happening here, but the train of
events is something like
    - you prepare a statement
    - somebody modifies the schema of one of the tables used in the
      statement
    - you try to execute the statement, and updating the prepared
      plan crashes

If you say "none of my stuff is changing any schemas", then I'd guess
that the triggering event is a background autovacuum, which forces
replan just like an intentional schema change would.  Does stopping
autovacuum make the problem go away?

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Alex Hunsaker"
Date:
Subject: Re: 8.3.0 backend segfaults
Next
From: Peter Eisentraut
Date:
Subject: Re: BUG #4027: backslash escaping not disabled in plpgsql