In response to Bill Moran <wmoran at collaborativefusion.com>:

> The second thing that surprised me is an odd limit on the size of the node
> ID.  As I already mentioned, we were trying to use node IDs that contain
> some intelligence (serial # style), so our node IDs were around 20000000.
> I didn't expect that to be a problem, since it's certainly small enough
> to fit in an int, but slonik gave a rather cryptic error:
> <stdin>:974: PGRES_FATAL_ERROR select "_clustername".initializeLocalNode(20000000, 'Local Slave node'); select "_clustername".enableNode_int(20000000);  - ERROR:  bigint out of range
> CONTEXT:  SQL statement "SELECT  setval('"_clustername".sl_rowid_seq',  $1 ::int8 * '1000000000000000'::int8)"
> PL/pgSQL function "initializelocalnode" line 26 at perform
> 
> Which makes it appear as if the node ID is being multiplied by one
> quadrillion before attempting to stuff it into a BIGINT.  when I set
> the node ID down to single-digits, the error stopped.

It appears as if this is happening to guarantee unique IDs for
Slony-generated primary keys across all nodes.

The thing is that it's only needed for tables that don't already have
primary keys, and in that case it's rather arbitrary.  It's making the
assumption that all the slony-generated primary keys on this node will
never exceed 10^15.  

I'm kind up in the air about this.  I would like to put together a patch
that will support longer node IDs, but 10^15 seems arbitrary, and anything
I'd change it to would be arbitrary as well.  The painful thing is that in
a database where all tables have primary keys, it's not needed anyway.

I expect that not a lot of people are having trouble with this, or there
would be more discussion about it up till now, but I'm curious if
anyone has ideas to contribute.

-- 
Bill Moran
Collaborative Fusion Inc.