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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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