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

Noah Misch <noah@leadboat.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