Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/5/12 Glyn Astill <glynastill@xxxxxxxxxxx>:
> --- On Wed, 12/5/10, Grzegorz Jaśkiewicz <gryzman@xxxxxxxxx> wrote:
>
>> Alban Hertroys
>> <dalroi@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>> 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!
>

ok, got it.

-- 
GJ

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux