On 07/02/2013 12:11 PM, Raghav wrote:
>
>     What does your table stest look like on the replica?  Does it have a
>     column "name" ?
>
>     What DDL did you execute and in what order?  If you are adding or
>     dropping the "name" column then this sounds like a bug, but more
>     details so we can reproduce this would be helpful.
>
>
> Sure. I have created a test case and implemented on both slony versions,
> stabled(2.1.2) & BETA(2.2.0).
>
> Steps:
> 1. Create a table with one column and few rows:
>      create table stest(id int primary key);
>      insert into stest values(generate_series(1,5));
> 2. Configure slony (initialization, create & subscribe) in SLON ARCHIVE
> mode(slon -a).
> 3. Once sync catch up, execute DDL command without using EXECUTE SCRIPT
> (like user error)
> ALTER TABLE STEST ADD COLUMN NAME TEXT;
> INSERT INTO STEST VALUES (10,'TEST);
>
> Observations in Slony 2.1.2 on above scenario:
>
> 1. DDL caused replication to crash if its executed without using EXECUTE
> SCRIPT(expected behavior) . Below log message is example of crash when I
> executed a DDL.
>
> 2013-06-15 16:36:26 IST ERROR  remoteWorkerThread_1: "insert into
> "public"."stest" ("id","name") values (10,'TEST');
> " ERROR:  column "name" of relation "stest" does not exist
> LINE 1: insert into "public"."stest" ("id","name") values ('1','...
> ....
> 2013-06-15 16:36:26 IST ERROR  remoteWorkerThread_1: SYNC aborted
>
> 2. Archives didn't captured the ALTER TABLE command, however an INSERT
> immediate after ALTER has been captured in archives.
> -bash-4.1$ fgrep -i alter *
> -bash-4.1$ fgrep -i insert *
> slony1_log_2_00000000000000000021.sql.tmp:insert into "public"."stest"
> ("id","name") values ('10','TEST');
>
> Observation in 2.2.0B on above scenario:
>
> 1.  Executing DDL, didn't impact the replication whatsoever, in the
> sense it didn't crashed. It just paused the replication. (I waited for
> almost 15 minuts and tried few DMLs on the table).

I can reproduce this.  Replication stops and I see things in the slon 
log like:


2013-07-02 13:39:03 EDT INFO   remoteWorkerThread_1: syncing set 1 with 
1 table(s) from provider 1
2013-07-02 13:39:03 EDT ERROR  remoteWorkerThread_1_1: error at end of 
COPY IN: ERROR:  Slony-I: type lookup for column name failed in logApply()
CONTEXT:  COPY sl_log_1, line 1: "1	1068182	1	1	public	stest	I	0 
{id,10,name,TEST}"



This is the new error that you get with slony 2.2.  That is the 
behaviour I would expect, very similar to 2.1 except the message is 
different


> 2.  Interesting, neither DDL nor DML's captured by archives in this version.
> -bash-4.1$ fgrep -i alter *
> -bash-4.1$ fgrep -i insert *
> -bash-4.1$
>

The DML actually is captured (at least for me) but the .sql files in 2.2 
use COPY not insert.

Try
fgrep -i stest *

Mine looks like:

COPY "_test"."sl_log_archive" ( log_origin, 
log_txid,log_tableid,log_actionseq,log_tablenspname, log_tablerelname, 
log_cmdtype, log_cmdupdncols,log_cmdargs) FROM STDIN;
1       1068182 1       1       public  stest   I       0 
{id,10,name,TEST}


The DDL isn't captured though, this is an omission that we probably 
should fix.

Also, are there places in the documentation where we need to be more 
clear on the changes in 2.2, particularly saying that the log shipping 
format has changed ? ( I am open to ideas on where)




> Please let me know if any further information required from my end.
>
> --Raghav