Cyril SCETBON <scetbon at echo.fr> writes:
>> I set up a "node 201", and 512 simple tables, and had no trouble
>> wrapping it with a little bit of extra slonik to make it work.
>>
> I suppose, you did not get the segmentation fault error

Correct, I did not get a segmentation fault.

>> At the moment, it's 350-odd tables into the subscription process; I
>> don't anticipate any problems.
>>
> I get the error immediately when I launch the slonik script that's why
> I think it's a parsing error.
>
> It's really seems to be a buggy piece of code.

And that does not particularly make sense in that:
a) I can't duplicate the problem,
b) Others haven't been reporting similar problems.

We didn't create a parser out of whole cloth; we are using Flex and
Bison, which are *widely* used for this purpose.  The FSF periodically
releases updates, demonstrating that bugs are periodically found,
however, we're not using any of the sorts of edges of these tools that
would lead me to expect us to be encountering bugs with those tools.

There has *got* to be some difference between our environments that is
leading to this difference in behaviour; what more can you tell us
about your environment?

- What OS platform?
- What version of PostgreSQL?
- What version of Slony-I?
- How did you get Slony-I installed (e.g. - "downloaded a binary RPM", or
  "built from sources," ...)?

I recall (can't find it in notes :-() a patch not too long back where
we had a case where we ran free() on some arguments in slonik.c before
we used the values; it worked fine on all the platforms we had tried
this on, but someone had a platform where memory allocation worked
slightly differently and that broke.  Given some precise version
information, maybe we can discover what is special about your platform
that something's breaking there.
-- 
let name="cbbrowne" and tld="linuxdatabases.info" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/wp.html
THERE'S TOO MUCH BLOOD IN MY CAFFEINE SYSTEM!!