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  (Jeremy Drake <pgsql@jdrake.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)