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 a lot.
>
> Michael
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general