Just one more thing, which might be important. The table I updated has a
unique index containing one column which is nullable, and the update
actually was targeting a row where that column was null.
Anyway, if having nullable columns in the unique index is a problem,
adding the table to the replication set should fail I guess... but it
did succeed. I actually used the altperl tools for the bulk of the
operations, but this particular table I added using pgAdmin3. In fact
the subscription worked fine, the table was replicated on the slave
without problems...

Is it possible that this is the cause of the signal 11 ?

Cheers,
Csaba.

On Thu, 2006-07-06 at 13:51, Csaba Nagy wrote:
> Hi all,
> 
> I'm new to this list, and to Slony1 in general.
> 
> I've tried out Slony 1.1.5 to replicate a sizable data base (~100G files
> on the master, a bit bloated though as the replica went only to 50G)
> between postgres 8.0.5 and 8.1.3 (I want to upgrade postgres as
> painlessly as possible).
> 
> Postgres was compiled from sources on both master/slave machines (which
> are debian linux both), and slony compiled and installed from sources
> too on both machines. Both machines are test servers, with the master
> holding a dump of the live data.
> 
> The replication worked fine, the DBs were synced in ~4 hours. I had to
> drop/recreate the foreign keys on the slave to avoid the truncate bug
> which makes the deferring of indexes impossible for tables referenced by
> foreign keys, but that is an acceptable workaround. With the foreign
> keys in place subscribing did not finish after 24 hours, and I stopped
> it...
> 
> The main problem is that when I tried now to make a simple update on a
> table on the master server, I got a signal 11 in the backend:
> 
> :16153::2006-07-06 13:26:03 CEST:LOG:  server process (PID 15857) was
> terminated by signal 11
> :16153::2006-07-06 13:26:03 CEST:LOG:  terminating any other active
> server processes
> 
> In the slony logs I found:
> 
> 2006-07-06 13:25:19 CEST FATAL  syncThread: "start transaction;set
> transaction isolation level serializable;select last_value
> from "_test_cluster".sl_action_seq;" - server closed the connection
> unexpectedly
>         This probably means the server terminated abnormally
>         before or while processing the request.
> 2006-07-06 13:25:19 CEST DEBUG1 slon: shutdown requested
> 
> The time stamps are not accurate, I retried a few times and I pasted
> here different trials for the server/slony log.
> 
> Where should I look for the problem ? I'm pretty sure I used the correct
> postgres/slony sources combination so it's not a mismatch in binaries...
> 
> Cheers,
> Csaba.
> 
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general