On Fri, 14 Jul 2006, Christopher Browne wrote:

A few I've found

<stdin>:4: PGRES_FATAL_ERROR select "_test_cluster".setAddTable(1, 1, 
'public.test', 'test_pkey', 'public.test');  - ERROR:  Slony-I: 
setAddTable(): set 1 has remote origin

If you get the origin wrong.  This error message isn't horrible but it isn't 
clear that "node 1 is not the current master of set 1"

Also, if executing commands through slonik the first part of the error 
message can be a bit intimidating to users.  A DBA setting up replication 
doesn't care that slonik is encountered the error calling the plpgsql 
function setAddTable() and might not get beyond the first part to the more 
friendly detail message.



When trying to add a sequence using the 1.2RC to a set that is 
already in the set.

<stdin>:5: PGRES_FATAL_ERROR select "_test_cluster".setAddSequence(1, 2, 
'public.iseq', 'public.iseq');  - ERROR:  duplicate key violates unique 
constraint "sl_sequence-pkey"
CONTEXT:  SQL statement "insert into "_test_cluster".sl_sequence (seq_id, 
seq_reloid, seq_relname, seq_nspname, seq_set, seq_comment) values ( $1 , 
$2 ,  $3 ,  $4 ,  $5 ,  $6 )"
PL/pgSQL function "setaddsequence_int" line 64 at SQL statement
SQL statement "SELECT  "_test_cluster".setAddSequence_int( $1 ,  $2 ,  $3 , 
$4 )"
PL/pgSQL function "setaddsequence" line 36 at perform


Same with adding a table that is already in the set
<stdin>:5: PGRES_FATAL_ERROR select "_test_cluster".setAddTable(1, 2, 
'public.test', 'test_pkey', 'public.test');  - ERROR:  duplicate key 
violates unique constraint "sl_table_tab_reloid_key"
CONTEXT:  SQL statement "insert into "_test_cluster".sl_table (tab_id, 
tab_reloid, tab_relname, tab_nspname, tab_set, tab_idxname, tab_altered, 
tab_comment) values ( $1 ,  $2 ,  $3 ,  $4 ,  $5 ,  $6 , false,  $7 )"
PL/pgSQL function "setaddtable_int" line 92 at SQL statement
SQL statement "SELECT  "_test_cluster".setAddTable_int( $1 ,  $2 ,  $3 ,  $4 
, $5 )"
PL/pgSQL function "setaddtable" line 37 at perform







> One of the issues that came up in the meeting at the PostgreSQL
> Anniversary Summit was that there are cases where you can get pretty
> non-self-explanatory error messages, and that they'd like to see
> something better.
>
> This is most frequently the case when something violates a uniqueness
> constraint.
>
> For instance, Norman Yamada recently reported problems where his slon
> processes would bust when processing a DDL script with the rather opaque:
>
> PGRES_FATAL_ERROR ERROR:  duplicate key violates unique constraint  "pg_trigger_tgrelid_tgname_index"
> CONTEXT:  SQL statement "update "pg_catalog".pg_trigger set tgrelid =  $1  where tgrelid =  $2 "
>
> And it was very much NOT obvious what trigger was involved...
>
> I recently introduced a change to the relevant code that will cause the complaint to be more like:
>
> Slony-I: multiple instances of trigger price_ins on table foo
> Slony-I: multiple instances of trigger price_before_del on table foo
> Slony-I: multiple instances of trigger price_before_ins_upd on table foo
> Slony-I: Unable to disable triggers
>
> That seems likely to make that particular case rather less mysterious.
>
> While at the Code Sprint, I walked through the pl/pgsql code, looking for cases where it looked like there were other opportunities for this; no more of them leaped out at me, but, mind you, I was pretty fried after not really having had a weekend :-).
>
> If there are cases where you have gotten a particularly useless error message, I'd appreciate hearing about it, at least if it's from a somewhat modern Slony-I version, as later releases tend to have fewer cases where the errors aren't being trapped so we can report something meaningful.
>
> I can't promise that every improvement anyone might imagine will take place, but hopefully there can be further improvement.
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>