On Tue, Jan 17, 2012 at 1:23 PM, Noah Misch wrote:
> On Mon, Jan 16, 2012 at 08:54:53PM -0500, Robert Haas wrote:
>> On Sun, Dec 18, 2011 at 11:53 AM, Noah Misch wrote:
>> > Here's a version that calls sigsetjmp() once per file. ?While
>> > postgresql.conf
>> > scanning hardly seems like the pla
On Mon, Jan 16, 2012 at 08:54:53PM -0500, Robert Haas wrote:
> On Sun, Dec 18, 2011 at 11:53 AM, Noah Misch wrote:
> > 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
On Sun, Dec 18, 2011 at 11:53 AM, Noah Misch wrote:
> 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().
This strikes
On Sat, Dec 17, 2011 at 11:04:43PM -0500, Tom Lane wrote:
> Noah Misch 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
Noah Misch 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
While testing the configuration include directory patch, I decided to try
the regular postgresql.conf "include" on a directory:
include 'base'
Reloading the configuration then rather rudely kills the postmaster:
FATAL: input in flex scanner failed
Setting aside whether we should offer a be
