Don Barthel wrote:
> Jeff:
>
> Thanks for your help.
>
> I have some big/complicated indexes on one particular table and since
> I have lots of memory to spare I've just now increased my
> shared_buffers from 20000 to 40000 (and SHMMAX at the OS level
> appropriately) and reload'ed postgresql but things are still
> progressing slowly.
>
> I notice in my /var/log/messages on the origin (and not on the
> subscriber) this:
>
> May 16 14:55:26 coliseum postgres[21817]: [1-1] ERROR:  duplicate key
> violates unique constraint "sl_nodelock-pkey"
>
> sl=slon, right?
>
> Doing this: select * from "_usedstuff".sl_nodelock; I get:
>
> nl_nodeid | nl_conncnt | nl_backendpid
> -----------+------------+---------------
>         1 |          0 |         18083
>         2 |         10 |         18089
>         2 |         11 |         18090
>
> Only three records. And I notice that the index on this table is:
> "sl_nodelock-pkey" PRIMARY KEY, btree (nl_nodeid, nl_conncnt)
>
> This looks like a problem to me but I cannot fathom where to start to
> fix it. Any clues? Thanks in advance!
This would normally result from trying to start up a second slon process
when one is already running.

The constraint on sl_nodelock prevents two slon processes from trying to
work on things at the same time, and consequently mussing things up.

The error message is more an indication that Slony-I *prevented*
something bad from happening...