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 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.
It seems plainly hackish to mutate the body of yy_fatal_error() by #define'ing
fprintf(). Why didn't we instead #define YY_FATAL_ERROR and provide our own
complete replacement? (Both strategies are undocumented.) I haven't changed
that decision in this patch, though.
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. guc.c has functions
like guc_malloc that handle variable elevels. However, various check_* and
assign_* functions, such as check_log_destination(), use pstrdup() and
guc_malloc(ERROR). Failing there during a reload would also kill the
postmaster. Is it worth doing better here?
Incidentally, the wal writer process no longer exits promptly on postmaster
death. I didn't look into that further.
Thanks,
nm