On Tuesday 05 December 2006 05:51, cbbrowne at ca.afilias.info wrote:
> > On Friday 01 December 2006 15:18, Christopher Browne wrote:
> >> If Darcy has opportunity to look at #1609, that would be a nice thing;
> >> there's apparently some small problem with the slon.conf file parser;
> >> it evidently chokes if there is not a [cr/lf] on the last line, which
> >> may represent something that may be trivially fixed.  If I can avoid
> >> Flex this week, I'll be just as happy ;-).
> >>
> >>   http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1609
> >
> > I looked into this, and I'm not seeing a syntax error problem when i test
> > it
> > on my FreeBSD box.  Can anybody else confirm this bug, and if so what OS
> > ?
>
> I can confirm it as observed on AIX...
>
> I just saw it now...
>
> postgres at TOR-520-TST902:/opt/home/postgres $ /opt/dbs/pgsql74_tld/bin/slon
> -f /opt/scripts/clusters/oxrstld/conf/node3.conf.fudged
> 2006-12-05 13:49:10 UTC ERROR  syntax error in file
> "/opt/scripts/clusters/oxrstld/conf/node3.conf.fudged" line 104, near end
> of line2006-12-05 13:49:10 UTC CONFIG main: slon version 1.1.5 starting up
> usage: /opt/dbs/pgsql74_tld/bin/slon [options] clustername conninfo
>
> I used dd to chop out the last character from node3.conf, creating
> node3.conf.fudged...


Ok I think I got it then,   Can you try in included patch ?


Index: conf-file.l
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/src/slon/conf-file.l,v
retrieving revision 1.7
diff -u -r1.7 conf-file.l
--- conf-file.l 29 Nov 2006 20:21:54 -0000      1.7
+++ conf-file.l 5 Dec 2006 13:57:41 -0000
@@ -186,8 +186,8 @@
                                }
                                parse_state = 2;
                                break;
-                       case 2: /* OEL ? */
-                               if (token != SLON_EOL)
+                       case 2: /* End Of Line or File ? */
+                               if (token != SLON_EOL && token != 0)
                                {
                                         goto parse_error;
                                }