Re: Postgresql 8.4.1 segfault, backtrace
| От | Tom Lane |
|---|---|
| Тема | Re: Postgresql 8.4.1 segfault, backtrace |
| Дата | |
| Msg-id | 1845.1253836663@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Postgresql 8.4.1 segfault, backtrace (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Postgresql 8.4.1 segfault, backtrace
Re: Postgresql 8.4.1 segfault, backtrace |
| Список | pgsql-bugs |
"Michael Brown" <mbrown@fensystems.co.uk> writes:
> I have put in place a temporary workaround on the production system, which
> is to insert a
> // Pretend that the cache is always invalid
> fprintf ( stderr, "*** bypassing cache ***\n" );
> goto read_failed;
I don't think this will actually help --- if anything it exposes you
to the bug more :-(. Given my current theory, there is not anything
wrong with the init file. The problem is a sort of race condition
that would be triggered by very high cache-inval traffic during startup
of a new backend. I looked at the cache inval array in your coredump,
and it looked like there had been a whole bunch of table deletions
happening concurrently with the startup --- "whole bunch" meaning
hundreds if not thousands. Is there anything in your application
behavior that might encourage a lot of table drops to happen
concurrently?
I'll get you a real fix as soon as I can, but might not be till
tomorrow.
regards, tom lane
В списке pgsql-bugs по дате отправления: