A fatal scanner error (likely a memory exhaustion problem) causes a
straight exit() without clean up, which causes a system-wide restart.
This should fix it:

*** scan.l      2001/01/24 19:43:03     1.85
--- scan.l      2001/01/27 14:14:29
***************
*** 55,60 ****
--- 55,62 ----
  /* No reason to constrain amount of data slurped per myinput() call. */
  #define YY_READ_BUF_SIZE 16777216

+ #define YY_FATAL_ERROR(msg) elog(FATAL, "%s", (msg))
+
  #else /* !FLEX_SCANNER */

  #undef input

But you will now get an unavoidable

scan.c:2145: warning: `yy_fatal_error' defined but not used

Objections or concerns?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Sat, 27 Jan 2001 15:25:03 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Ungraceful handling of fatal flex errors
Peter Eisentraut <peter_e@gmx.net> writes:
> A fatal scanner error (likely a memory exhaustion problem) causes a
> straight exit() without clean up, which causes a system-wide restart.
> This should fix it:

> *** scan.l      2001/01/24 19:43:03     1.85
> --- scan.l      2001/01/27 14:14:29
> ***************
> *** 55,60 ****
> --- 55,62 ----
>   /* No reason to constrain amount of data slurped per myinput() call. */
>   #define YY_READ_BUF_SIZE 16777216

> + #define YY_FATAL_ERROR(msg) elog(FATAL, "%s", (msg))
> +
>   #else /* !FLEX_SCANNER */

>   #undef input

> But you will now get an unavoidable

> scan.c:2145: warning: `yy_fatal_error' defined but not used

I have a sneakier idea to avoid the warning.  The yy_fatal_error routine
is defined as

	(void) fprintf( stderr, "%s\n", msg );
	exit( YY_EXIT_FAILURE );

and this is the only use of fprintf in the scan.c file.  How about
leaving yy_fatal_error as the error subroutine, and insert

#define fprintf(file,fmt,msg)  elog(FATAL, "%s", (msg))


			regards, tom lane

Sat, 27 Jan 2001 11:15:39 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Ungraceful handling of fatal flex errors 
> 
> > scan.c:2145: warning: `yy_fatal_error' defined but not used
> 
> I have a sneakier idea to avoid the warning. [...]
> 
> #define fprintf(file,fmt,msg)  elog(FATAL, "%s", (msg))

  Meaning no disrespect : yuck... IMHO this is asking for trouble
whenever someone decides to use another yacc. One should never ever
use the preprocessor to do what it was originally intended for
:-). Why not just make a useless statement calling yy_fatal_error ? 

--- scan.l.orig	Mon Jan 29 11:36:56 2001
+++ scan.l	Mon Jan 29 11:27:28 2001
@@ -532,6 +534,9 @@
 	   because input()/myinput() checks the non-nullness of parseCh
 	   to know when to pass the string to lex/flex */
 	parseCh = NULL;
+
+	/* Make a bogus use of yy_fatal_error to avoid spurious warning */
+	(void) &yy_fatal_error;
 
 	/* initialize literal buffer to a reasonable but expansible size */
 	literalalloc = 128;

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

			Dominique Quatravaux <dom@kilimandjaro.dyndns.org>

Mon, 29 Jan 2001 11:39:03 +0100
dom@idealx.com, dom@idealx.com
Re: Ungraceful handling of fatal flex errors
dom@idealx.com, dom@idealx.com writes:
>> #define fprintf(file,fmt,msg)  elog(FATAL, "%s", (msg))

>   Meaning no disrespect : yuck... IMHO this is asking for trouble
> whenever someone decides to use another yacc.

This is flex, not yacc, and our lexer has been flex-only for a long
time.  It's possible that the hack would break in a future version
of flex, but I doubt it.  What else is a lexer going to use fprintf
for?

			regards, tom lane

Mon, 29 Jan 2001 09:43:35 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Ungraceful handling of fatal flex errors 
> This is flex, not yacc, and our lexer has been flex-only for a long
> time.  It's possible that the hack would break in a future version
> of flex, but I doubt it.  What else is a lexer going to use fprintf
> for?

  Hmm, well of course you are right... (and I could use some sleep too
:-). OK, this becomes a non-issue then.

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

			Dominique Quatravaux <dom@kilimandjaro.dyndns.org>

Mon, 29 Jan 2001 20:25:36 +0100
dom@idealx.com
Re: Ungraceful handling of fatal flex errors