Hi,
 
Thanks for the help. 
 
I tried to do the same process of deleting a table on the receiving end. But now the slon doesn't seem to react at all. I updated tables on the provider, but it does nothing.
It doesn't give the error message it gave before. What could be the problem this time?
 
And also, last time I deleted the tables and recreated them manually. The table definitions were the exact same as on the provider. But when I restarted the slon daemons, it gave me the same error message and did not replicate.
 
Thanks,
Saranya
 


Christopher Browne <cbbrowne at ca.afilias.info> wrote:
sarlav kumar wrote:

> Hi All,
> 
> Thank for all the help everybody. I closed the shells and tried doing 
> the replication again, and it worked. Not sure what was going wrong 
> earlier.
> 
> The tables got replicated in the test_slave database.
> 
> I tried to drop the one of the tables in test_slave database and it 
> actually allowed to drop the table while it was getting replicated!
>
How would you imagine that Slony-I could prevent you from doing that?

> The Slon process gives the following error message:
> 
> ERROR remoteWorkerThread_1: "declare LOG cursor for select 
> log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, 
> log_cmddata from "_test".sl_log_1 where log_origin = 1 and ( order by 
> log_actionseq; " PGRES_FATAL_ERROR ERROR: syntax error at or near 
> "order" at character 163
> ERROR remoteWorkerThread_1: "close LOG; " PGRES_FATAL_ERROR ERROR: 
> current transaction is aborted, commands ignored until end of 
> transaction block
> ERROR remoteWorkerThread_1: helper 1 finished with error
> ERROR remoteWorkerThread_1: SYNC aborted
> Is this how slony has to react when a replicated table(on the 
> receiving end) is deleted while replication is going on? Would the 
> same thing happen if I delete a table that is providing data, while 
> replication is going on?

That seems pretty consistent with what I'd expect to happen. You 
corrupted the configuration of replication by dropping tables out from 
under the replication system, at which point some of its queries won't 
succeed properly.

If you dropped a replicated table on an origin node, you'd be less 
likely to see the problem, as an origin node never needs to declare LOG 
cursors. You might be able to "get away with it," although I'd never 
want to promise that.

> While the slon daemons where running, I also tried to add the same 
> set of tables manually in the test_slave DB, but replication does not 
> continue.Why is that the case?

I take it that what you did was to try to add the tables back by hand. 
That won't help, because the replication configuration on the subscriber 
is still pointed to the table that you dropped. sl_table doesn't 
contain the name of the table; it contains the OID.

> If I dont do a pg_dump as shown in the example replication, but 
> manually create the schema for the tables to be replicated on 
> test_slave DB, slon daemon would not replicate the data, Am I right? 
> If this is right, can someone please explain why?

No, you're probably wrong about that. It's not forcibly necessary to 
use a pg_dump; it's just necessary for the DDL to be "sufficiently 
similar" between origin and subscriber nodes. They need to be "similar 
enough" that the SUBSCRIBE_SET event on the subscriber will transform 
the subscriber's schema to be compatible with the data being provided at 
the origin.

It sounds like you're trying to figure out how badly broken your usage 
can be and still work; that doesn't sound to me like a useful path to take.
-- 


		
---------------------------------
Do you Yahoo!?
 Yahoo! Mail - You care about security. So do we.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20050104/f1d55b4c/attachment.html