Re: 8.3.0 backend segfaults - Mailing list pgsql-bugs

From Alex Hunsaker
Subject Re: 8.3.0 backend segfaults
Date
Msg-id 34d269d40803120842l31efdf12t7965e286af562e2b@mail.gmail.com
Whole thread Raw
In response to Re: 8.3.0 backend segfaults  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 8.3.0 backend segfaults
List pgsql-bugs
On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "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?

Yep turning off autovacuum seems to have fixed it.  And once I
manually vacuum analyze workers; it blows up almost instantly.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.3.0 backend segfaults
Next
From: "Alex Hunsaker"
Date:
Subject: Re: 8.3.0 backend segfaults