> some intelligence (serial # style), so our node IDs were around 
> 20000000.

Looks like a unique ID collision avoidance technique.  Presumably you 
can't really put lot of restraints on Slony tables themselves and 
guarantee synchronicity (did i really just say that?)

# select * from _cores_minnesota_2.sl_rowid_seq  ;
  sequence_name |    last_value    | increment_by |      max_value      | 
min_value | cache_value | log_cnt | is_cycled | is_called

---------------+------------------+--------------+---------------------+---

sl_rowid_seq  | 2000000000000000 |            1 | 9223372036854775807 | 
1 |           1 |       0 | f         | t

(1 row)


Well, an 8 digit number going by your scheme at max: 99999999 * 
1000000000000000 is well > max(int8) which is 9223372036854775808

$ echo 1000000000000000 | wc -c
       17

Where I work, that value seems completely arbitrary (Chris?) so feel free 
to change it.  Also, where I'm at, I use a similar scheme for mapping 
POSIX UIDs into Windows NT UUIDs in Samba/LDAP.

The assumption here is very small Node IDs, which is bollocks if you're 
running more than one slon(8) instance on a machine your logs will fill 
with many unreadable messages from different slon(8) PIDs that do not have 
unique node IDs.

~BAS

---------

$ more src/backend/slony1_funcs.sql
[...snip[
create or replace function @NAMESPACE at .initializeLocalNode (int4, text)
returns int4
as '
declare
         p_local_node_id         alias for $1;
         p_comment                       alias for $2;
         v_old_node_id           int4;
         v_first_log_no          int4;
         v_event_seq                     int8;
begin
         -- ----
         -- Grab the central configuration lock
         -- ----
         lock table @NAMESPACE at .sl_config_lock;

         -- ----
         -- Make sure this node is uninitialized or got reset
         -- ----
         select last_value::int4 into v_old_node_id from 
@NAMESPACE at .sl_local_node_id;
         if v_old_node_id != -1 then
                 raise exception ''Slony-I: This node is already 
initialized'';
         end if;

         -- ----
         -- Set sl_local_node_id to the requested value and add our
         -- own system to sl_node.
         -- ----
         perform setval(''@NAMESPACE at .sl_local_node_id'', p_local_node_id);
         perform setval(''@NAMESPACE at .sl_rowid_seq'',
                         p_local_node_id::int8 * 
''1000000000000000''::int8);
         perform @NAMESPACE at .storeNode_int (p_local_node_id, p_comment, 
false);

         return p_local_node_id;
end;
' language plpgsql;

comment on function @NAMESPACE at .initializeLocalNode (int4, text) is
   'no_id - Node ID #
no_comment - Human-oriented comment


> 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.
>
> -- 
> Bill Moran
> Collaborative Fusion Inc.
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>

l8*
 	-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
 	       http://www.spiritual-machines.org/

"...from back in the heady days when "helpdesk" meant nothing, "diskquota"
meant everything, and lives could be bought and sold for a couple of pages
of laser printout - and frequently were."