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

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