Re: Cache lookup failed for relation, when trying to DROP
От | Jan Wieck |
---|---|
Тема | Re: Cache lookup failed for relation, when trying to DROP |
Дата | |
Msg-id | 41741C6C.6000507@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Cache lookup failed for relation, when trying to DROP (Mark Gibson <gibsonm@cromwell.co.uk>) |
Список | pgsql-general |
On 10/15/2004 4:20 AM, Mark Gibson wrote: > Andrew Sullivan wrote: >> On Wed, Oct 06, 2004 at 05:25:58PM +0100, Mark Gibson wrote: >> >>>I had to remove Slony's schema manually as I was having problems >>>with it. I was in the process of removing all Slony related stuff, >>>and all my slave tables when this problem occurred, and was going to >>>start again from scratch. >> >> Did your problem happen on a replica, or on the origin? There's a >> current dirty, evil hack in Slony that does extremely naughty things >> in the catalogues on the replicas. This is slated to go away in the >> future, but at the moment it's possible to trip over it if you don't >> use Slony's own admin tools. > > Yes it was on the slave. After a bit more playing with Slony, I've > discovered the cause. I'd created rules on a slave table before > subscribing it to the master, Slony was disabling the rule from > within pg_catalog, so when I manually removed Slony I had some > rogue rules floating around. PostgreSQL didn't know it needed to > drop the rules but it was being restricted from dropping the table > by unknown deps in pg_depend. > Yes, this is the ugly bit of catalog scrbbling Slony-I 1.0 does. We have ideas to clean this up in 1.1. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-general по дате отправления: