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

On Sat, Dec 17, 2011 at 11:04:43PM -0500, Tom Lane wrote:
> 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.

On the contrary, I want to make it even more of a hack to get better behavior!

Here's a version that calls sigsetjmp() once per file. While postgresql.conf
scanning hardly seems like the place to be shaving cycles, this does catch
fatal errors in functions other than yylex(), notably yy_create_buffer().

> > 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.

Works for me.

Thanks,
nm