|
Home > Archive > Slony1 PostgreSQL Replication > July 2005 > Re: ERROR: cache lookup failed for relation 438095645
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: ERROR: cache lookup failed for relation 438095645
|
|
| Jan Wieck 2005-07-07, 8:30 pm |
| On 7/7/2005 2:44 PM, Joe Markwardt wrote:
[color=darkred]
> On Thu, 2005-07-07 at 12:21 -0400, Jan Wieck wrote:
after reading the entire thread it appears that you attempted to drop
the table on the subscriber before the event for removing the table from
the set actually propagated to the subscriber. That would be the only
chance that the denyaccess trigger is still defined for it and the
foreign key triggers are still "parked" on the tables PK index (that's
one of the weird things Tom was talking about).
Jan
[color=darkred]
>
> First I ran a slonik script to remove the table from the replication set
> using the SET DROP TABLE slonik command. After that I then ran "DROP
> TABLE pl_inventory_analyze
r_files;" by hand from the psql command line,
> first on the database server that was the provider, then on the server
> that was the subscriber. I thought that once I had successfully ran the
> "SET DROP TABLE" that I could then modify the table at will. Did I
> forget or misinterpret something?
>
>
> I use execute script for all minor changes to tables that are in the
> replication set. If its a major change ( like this one was, basically
> changing over half the columns in the table, requiring a reload of the
> data in this table ) I will usually follow the procedure outlined
> above, then re-create the table, use a temp set and merge set to get
> replication going on the new table, then load the data. It has worked
> successfully so far.
>
> Thanks
> Joe
>
--
#===================
====================
====================
===========#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#===================
====================
=========== JanWieck- bwPqjjyvM7QAvxtiuMwx
3w@public.gmane.org #
| |
| Christopher Browne 2005-07-08, 11:24 am |
| Jan Wieck wrote:
> On 7/7/2005 3:31 PM, Joe Markwardt wrote:
>
>
>
> Since the table is still setup for replication and the drop table
> fortunately failed, I would assume that the SET_DROP_TABLE event is
> still sitting in the event queue. So restarting the slon on the
> subscriber should fix it. Or am I missing something here?
Ah, but if some event BEFORE that one keeps failing, it will never get
around to the SET_DROP_TABLE.
Suppose there is data to be replicated into that table before it is
dropped; that would Cause A Problem...
|
|
|
|
|