What are the limitations for table id in slony?

Question

I'm setting up postgres replication with slony. I have many schemas containing the same (or very similar) set of tables, so I create separate replications sets for every schema. Each schema has specific unique number, so this number becomes id of the set.

Then I add tables to replication. As far as I know every table has to have unique id across all tables. Because tables are created every month, the id for the table is concatenated from year, month and set id. Everything works fine, but when set id has four digits (so table id will be for example: 2015051162), it gives me an error after adding table to replication:

 2015-05-29 10:09:20 CEST INFO   remoteWorkerThread_1: syncing set 101162 with 1 table(s) from provider 1
 2015-05-29 10:09:22 CEST CONFIG slon: child terminated signal: 11; pid: 18738, current worker pid: 18738
 2015-05-29 10:09:22 CEST CONFIG slon: restart of worker in 10 seconds

It seems to me that this table id is too big, because for sets with single-digit ids everything replicates correctly. Are there any limitations for table id, except that it has to be unique in the replication cluster?

Answer 1

Are there limitations?

There's no hard limit, except that it should be an int.

But why does it fail?

As it appears, using high IDs does use up some memory, due to the way those IDs are stored. As per the fine documentation:

Note that Slony-I generates an in-memory array indicating all of the fully qualified table names; if you use large table ID numbers, the sparsely-utilized array can lead to substantial wastage of memory. Each potential table ID consumes a pointer to a char, commonly costing 4 bytes per table ID on 32 bit architectures, and 8 bytes per table ID on 64 bit architectures.

That means, if you generate a set of IDs with a biggest ID of, say, 5000 for 100 tables, slony would (try to) create an array which would be able to hold 5000 table entries. Only, that 4900 entries would be unused.

For an ID of 2015051162 you'd have to reserve space of 4 bytes (in 32 bit) * 2015051162 = about 8GB for this array, so the segfault is probably just about an unfilled request to the OS for that memory.