On Tue, 22 Nov 2011 10:25:57 -0500
"Steve Singer" <ssinger at ca.afilias.info> wrote:

> On 11-11-22 08:00 AM, Michael Cheung wrote:
> > Hi all;
> > (postgres version 8.3.16, slony version 2.1.0)
> >
> > While I run sql to create index on a huge table(named tableA) by slonik_execute_script,
> > (actually this operation cost me almost 20 min.)
> > And slonik_execute_script command end with following error message.
> >
> > <stdin>:5: NOTICE:  public.tableB has an invalid configuration on the log trigger. This was not corrected because
> > only_lock is true and the table is not locked.
> > CONTEXT:  SQL statement "SELECT  "_apl_repl1".repair_log_triggers(true)"
> > PL/pgSQL function "ddlscript_complete_int" line 5 at PERFORM
> > SQL statement "SELECT  "_apl_repl1".ddlScript_complete_int( $1 , $2 )"
> > PL/pgSQL function "ddlscript_complete" line 7 at PERFORM
> >
> > And I have check the new index on table A on every node, it is created and seems fine.
> > And record count on tableB is same on every node. Everything seems well.
> >
> > But anyone can tell me what happened with this message? And is it safe to just ignore it?
> >
> 
> If you look at the Slony log trigger on when of your tables it will look 
> something like this:
> 
> 
> _test_logtrigger AFTER INSERT OR DELETE OR UPDATE ON a FOR EACH ROW 
> EXECUTE PROCEDURE _test.logtrigger('_test', '1', 'kvk')
> 
> The 'kvk' means that the first column in the table is part of the key, 
> the second column is not part of a key(primary key or unique 
> constraint), and the third column makes up the second component of the 
> unique key.
> 
> If you do something to the table to change this, ie drop the second 
> column.  Then this argument order is no longer correct and slony needs 
> to recreate the logtrigger to have the correct arguments.   Doing that 
> will require an exclusive lock.  If EXECUTE SCRIPT in 2.1 determines 
> that the script has already taken out an exclusive lock on the table 
> then it will just fix the trigger.   However it won't go and obtain the 
> lock.
> 
> The function select _test.determineAttKindUnique('public.a','a_pkey'); 
> (where _test is your slony schema name) will tell you want the arguments 
> should be for a particular function.  Compare the output of that for 
> your tableB with the arguments on the trigger (\d in psql).
> 
> If you call _test.repair_log_trigger(false) it will take an exclusive 
> lock on the tables it requires and repair the trigger arguments.  (You 
> would need to do that on all nodes).
> 
Thanks for your guide in detail.
I do change the pkey for tableA before , and now I have repaired trigger on tableA
by repair_log_triggers as you said.

Thanks for your help.