Re: ALTER SYSTEM and ParseConfigFile()

Greetings,

While working through the pg_file_settings patch, I came across this
comment above ParseConfigFp() (which is called by ParseConfigFile()):

src/backend/utils/misc/guc-file.l:603
------------------------------------------------------
* Output parameters:
* head_p, tail_p: head and tail of linked list of name/value pairs
*
* *head_p and *tail_p must be initialized to NULL before calling the outer
* recursion level. On exit, they contain a list of name-value pairs read
* from the input file(s).
------------------------------------------------------

However, in 65d6e4c, ProcessConfigFile(), which isn't part of the
recursion, was updated with a second call to ParseConfigFile (for the
PG_AUTOCONF_FILENAME file), passing in the head and tail values which
had been set by the first call.

I'm a bit nervous that there might be an issue here due to how flex
errors are handled and the recursion, though it might also be fine
(but then why comment about it?).

In any case, either the comment needs to be changed, or we should be
passing clean NULL variables to ParseConfigFile and then combining the
results in ProcessConfigFile().

This is pretty orthogonal to the changes for pg_file_settings, so I'm
going to continue working through that and hopefully get it wrapped up
soon.

Thanks!

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Greetings,
> While working through the pg_file_settings patch, I came across this
> comment above ParseConfigFp() (which is called by ParseConfigFile()):

> src/backend/utils/misc/guc-file.l:603
> ------------------------------------------------------
> * Output parameters:
> * head_p, tail_p: head and tail of linked list of name/value pairs
> *
> * *head_p and *tail_p must be initialized to NULL before calling the outer
> * recursion level. On exit, they contain a list of name-value pairs read
> * from the input file(s).
> ------------------------------------------------------

> However, in 65d6e4c, ProcessConfigFile(), which isn't part of the
> recursion, was updated with a second call to ParseConfigFile (for the
> PG_AUTOCONF_FILENAME file), passing in the head and tail values which
> had been set by the first call.

> I'm a bit nervous that there might be an issue here due to how flex
> errors are handled and the recursion, though it might also be fine
> (but then why comment about it?).

> In any case, either the comment needs to be changed, or we should be
> passing clean NULL variables to ParseConfigFile and then combining the
> results in ProcessConfigFile().

I think the code is OK, but yeah, this comment should be changed to
reflect the idea that the function will append entries to an existing
list of name/value pairs (and thus, that head_p/tail_p are not output
but in/out parameters).

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> I think the code is OK, but yeah, this comment should be changed to
> reflect the idea that the function will append entries to an existing
> list of name/value pairs (and thus, that head_p/tail_p are not output
> but in/out parameters).

I've pushed a fix for the comment to address this.

Thanks!

Stephen

Stephen Frost wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > I think the code is OK, but yeah, this comment should be changed to
> > reflect the idea that the function will append entries to an existing
> > list of name/value pairs (and thus, that head_p/tail_p are not output
> > but in/out parameters).
>
> I've pushed a fix for the comment to address this.

This open-coded list thingy is pretty odd. I wonder if it'd be nicer to
replace it with ilist. (Not for 9.5, of course.)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> Stephen Frost wrote:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > > I think the code is OK, but yeah, this comment should be changed to
> > > reflect the idea that the function will append entries to an existing
> > > list of name/value pairs (and thus, that head_p/tail_p are not output
> > > but in/out parameters).
> >
> > I've pushed a fix for the comment to address this.
>
> This open-coded list thingy is pretty odd. I wonder if it'd be nicer to
> replace it with ilist. (Not for 9.5, of course.)

I have a feeling that much of the GUC machinery could be reworked; as
Jim mentioned up-thread, it might be possible to use memory contexts too
which would make a lot of it much cleaner, I believe.

Agreed that it's not for 9.5 though.

Thanks!

Stephen

* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> I have a feeling that much of the GUC machinery could be reworked; as
> Jim mentioned up-thread, it might be possible to use memory contexts too
> which would make a lot of it much cleaner, I believe.

Err, "on another thread", not on this one. :)

And Jim Nasby, to be more specific.

Thanks!

Stephen