In response to "Andrew Hammond" <andrew.george.hammond at gmail.com>:

> On 3/27/07, Bill Moran <wmoran at collaborativefusion.com> wrote:
> > 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.
> 
> Considering that people seem to agree that slony generated pkeys are
> more of a wart than a feature, why not simply deprecate the feature
> and remove it?

I tend to lean that way, since I've been making it a point to ensure that
all our tables have primary keys.  I believe it's not a big deal to
create them for Slony if they don't exist, and I'd rather intelligently
select a primary key than have Slony add an "arbitrary" bigint field.
Removing that capability would certainly simply the slony code.

However, I'm hoping to come up with an improvement that the community will
accept so it goes back into the tree.  My thought is that the capability
wouldn't be there if people weren't using it, so yanking it could cause
some upset.

-- 
Bill Moran
Collaborative Fusion Inc.