Jan Wieck wrote:
>> However, this is a serious bug since user defined tyes without any 
>> operators are of course legal in Postgres and have to be supported by 
>> Slony. I am working on a fix for it.
> 
> This is fixed in REL_1_0_STABLE and HEAD, so it will be included in the 
> upcoming version 1.0.3.

Thank you - it does seem to have fixed the crashes! :)

I'm now seeing a new issue when the initial copy starts up.  Slon logs 
this on my slave database:

----------------------------------
DEBUG1 copy_set 1
DEBUG1 remoteWorkerThread_1: connected to provider DB
DEBUG2 remoteWorkerThread_1: copy table public.category_dates
DEBUG2 remoteWorkerThread_1: 757207 bytes copied for table 
public.category_dates
DEBUG2 remoteWorkerThread_1: 1.712 seconds to copy table 
public.category_dates
DEBUG2 remoteWorkerThread_1: copy table public.categories
ERROR  remoteWorkerThread_1: "select 
"_T1".truncateTable('public.categories'); copy public.categories from 
stdin; " ERROR:  cannot truncate a table referenced in a foreign key 
constraint
DETAIL:  Table "category_tree" references "categories" via foreign key 
constraint "$1".
CONTEXT:  PL/pgSQL function "truncatetable" line 4 at execute statement
  ERROR:  cannot truncate a table referenced in a foreign key constraint
DETAIL:  Table "category_tree" references "categories" via foreign key 
constraint "$1".
CONTEXT:  PL/pgSQL function "truncatetable" line 4 at execute statement

WARN   remoteWorkerThread_1: data copy for set 1 failed - sleep 15 seconds
----------------------------------

Is slony unable to handle foreign key constraints?  I didn't see 
anything about that in the docs.

-Brad