Re: 8.3.0 backend segfaults
От | Alex Hunsaker |
---|---|
Тема | Re: 8.3.0 backend segfaults |
Дата | |
Msg-id | 34d269d40803120842l31efdf12t7965e286af562e2b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 8.3.0 backend segfaults (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 8.3.0 backend segfaults
|
Список | 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 по дате отправления: