Csaba Nagy <nagy at ecircle-ag.com> writes:
> 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 ?

You bet, that's exactly it.

Nullable columns in the candidate primary key are a no-no.

And there isn't an attempt to check that the columns are all NOT NULL;
I'll take a look today to see if that is something that can be easily
checked at the time of SET ADD TABLE.  That ought to be a good thing
to check.
-- 
output = reverse("ofni.sailifa.ac" "@" "enworbbc")
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)