On Tue, 22 Nov 2011 10:25:57 -0500
"Steve Singer" <[email protected]> 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.
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
