Re: 8.3.7, 'cache lookup failed' for a table

Поиск
Список
Период
Сортировка
Искать
От
Glyn Astill
Тема
Re: 8.3.7, 'cache lookup failed' for a table
Дата
в 07:23:11
Msg-id
593014.57824.qm@web23603.mail.ird.yahoo.com
Ответ на
Список
Дерево обсуждения
8.3.7, 'cache lookup failed' for a table Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: 8.3.7, 'cache lookup failed' for a table Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: 8.3.7, 'cache lookup failed' for a table Alban Hertroys <dalroi@solfertje.student.utwente.nl>
Re: 8.3.7, 'cache lookup failed' for a table Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: 8.3.7, 'cache lookup failed' for a table Glyn Astill <glynastill@yahoo.co.uk>
Re: 8.3.7, 'cache lookup failed' for a table Alban Hertroys <dalroi@solfertje.student.utwente.nl>
Re: 8.3.7, 'cache lookup failed' for a table Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: 8.3.7, 'cache lookup failed' for a table Glyn Astill <glynastill@yahoo.co.uk>
Re: 8.3.7, 'cache lookup failed' for a table Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: 8.3.7, 'cache lookup failed' for a table Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: 8.3.7, 'cache lookup failed' for a table Glyn Astill <glynastill@yahoo.co.uk>
Re: 8.3.7, 'cache lookup failed' for a table Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: 8.3.7, 'cache lookup failed' for a table Glyn Astill <glynastill@yahoo.co.uk>
Re: 8.3.7, `cache lookup failed` for a table "Greg Sabino Mullane" <greg@turnstep.com>
--- On Wed, 12/5/10, Grzegorz Jaśkiewicz  wrote:

> Alban Hertroys
> 
> wrote:
> > On 12 May 2010, at 12:01, Glyn Astill wrote:
> >
> >> Did you not mention that this server was a slony
> slave at some point though?
> >>
> >> Just because you have removed slony, and the error
> comes from postgresql itself does not mean the corruption
> was not caused by misuse of slony.
> >
> > Indeed. I wonder if "when we ere adding/removing slony
> to the system for Nth time (due to it sometimes going out of
> sync)" may be caused by that as well.
> >
> 
> ok, so either upgrade to newer version of slony, or drop
> all tables,
> and recreate them every time slony is removed and readded
> to the
> database.
> 

Upgrading to slony 2.03 would prevent this from happening, but no there's no need to drop and recreate all tables every time slony is removed and re-added to the database - you just need you make sure you use slonik SET DROP TABLE *before* dropping any table in postgresql. Look, here http://www.slony.info/documentation/stmtsetdroptable.html


> And I guess the only reason postgresql doesn't like it, is
> due to
> slony's behavior.
> 

Nope, due to slony not being used correctly!



В списке pgsql-general по дате отправления
От: Koichi Suzuki
Дата:
От: Grzegorz Jaśkiewicz
Дата:
FAQ