Skip site navigation (1) Skip section navigation (2)

Re: fatal flex error in guc-file.l kills the postmaster

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: fatal flex error in guc-file.l kills the postmaster
Date: 2011-12-18 04:04:43
Message-ID: 21049.1324181083@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Noah Misch <noah(at)leadboat(dot)com> writes:
> Setting aside whether we should offer a better diagnostic when a user points
> "include" at a directory, the yy_fatal_error hack that made sense for scan.l
> doesn't cut it for guc-file.l.  Like other guc-file.l errors, we need to
> choose the elevel based on which process is running the code.  ERROR is never
> the right choice.  We should instead stash the message, longjmp out of the
> flex parser, and proceed to handle the error mostly like a regular syntax
> error.  See attached small patch.

Well, if you're going to criticize the original method as being hackish,
you really need to offer a cleaner substitute than this one ;-).  In
particular I'm not happy with adding a sigsetjmp() cycle for every
single token parsed.

> It seems plainly hackish to mutate the body of yy_fatal_error() by #define'ing
> fprintf().

I agree, but the flex boys haven't provided any nicer API ...
at least not unless we'd like to convert to C++.

> Why didn't we instead #define YY_FATAL_ERROR and provide our own
> complete replacement?

For one reason, yy_fatal_error would still be there and would draw an
"unused static function" warning.

> On a related note, the out-of-memory handling during config file reload is
> inconsistent.  guc-file.l uses palloc/pstrdup in various places.  An OOM at
> those sites during a reload would kill the postmaster.

If you've got OOM in the postmaster, you're dead anyway.  I feel no
compulsion to worry about this.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: k_denisovDate: 2011-12-18 08:25:56
Subject: BUG #6344: Trouble with plperl
Previous:From: Craig RingerDate: 2011-12-17 06:19:14
Subject: Re: R: BUG #6342: libpq blocks forever in "poll" function

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group