Re: catalog corruption bug
От | Tom Lane |
---|---|
Тема | Re: catalog corruption bug |
Дата | |
Msg-id | 25909.1136746839@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: catalog corruption bug (Jeremy Drake <pgsql@jdrake.com>) |
Ответы |
Re: catalog corruption bug
|
Список | pgsql-hackers |
Jeremy Drake <pgsql@jdrake.com> writes: > On Sat, 7 Jan 2006, Tom Lane wrote: >> A bit of a leap in the dark, but: maybe the triggering event for this >> situation is not a "VACUUM pg_amop" but a global cache reset due to >> sinval message buffer overrun. > I tried that function you sent, while running my other code. It died, but > not the same way. None of my processes had the unique constraint error, > but two had failed during commit. Both of them died in that same place as > the last one, on pg_amop. Yeah, that's not very surprising. Running the forced-cache-resets function will definitely expose that catcache bug pretty quickly. You'd need to apply the patches I put in yesterday to have a system that has any chance of withstanding that treatment for any length of time. > I think I am going to just run without the function running this time and > see if it does the duplicate type error and if it will generate two cores. Please also look at putting together a test case so others can poke at this. regards, tom lane
В списке pgsql-hackers по дате отправления: