On 7/6/2006 8:23 AM, Csaba Nagy wrote:

> 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 ?

Indeed. Slony requires a UNIQUE NOT NULL column set to identify a row. 
Duplicate NULL values do not count as duplicate keys, so if any of the 
columns is nullable, the key becomes useless. I originally didn't bother 
to check inside the log trigger if a key attribute is NULL (we have 
fixed that in the CVS), because such key is useless in the first place, 
so the log trigger should not expect to be confronted with that.


Jan

> 
> 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
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #