Re: Semantics of pg_file_settings view - Mailing list pgsql-hackers

Sawada Masahiko <sawada.mshk@gmail.com> writes:
> On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However there's a further tweak to the view that I'd like to think about
>> making.  Once this is in and we make the originally-discussed change to
>> suppress application of duplicated GUC entries, it would be possible to
>> mark the ignored entries in the view, which would save people the effort
>> of figuring out manually which ones were ignored.  The question is exactly
>> how to mark the ignored entries.  A simple tweak would be to put something
>> in the "error" column, say "ignored because of later duplicate entry".
>> However, this would break the property that an entry in the error column
>> means there's something you'd better fix, which I think would be a useful
>> rule for nagios-like monitoring tools.
>> 
>> Another issue with the API as it stands here is that you can't easily
>> distinguish errors that caused the entire config file to be ignored from
>> those that only prevented application of one setting.
>> 
>> The best idea I have at the moment is to also add a boolean "applied"
>> column which is true if the entry was successfully applied.  Errors that
>> result in the whole file being ignored would mean that *all* the entries
>> show applied = false.  Otherwise, applied = false with nothing in the
>> error column would imply that the entry was ignored due to a later
>> duplicate.  There are multiple other ways it could be done of course;
>> anyone want to lobby for some other design?

> I think that we can find applied value by arranging
> pg_file_settings.seqno ascending order.
> The value which has highest seqno is the currently applied value, and
> it's default value if pg_file_settings does not have that entry.

Yeah, I realize that it's *possible* to get this information out of the
view as it stands.  But it's not especially *convenient*.  And since this
seems like the main if not only use-case for the view (at least prior to
the addition of error information), I don't see why we insist on making it
difficult for users to identify ignored entries.

> (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
>                                          errmsg("parameter \"%s\"
> cannot be changed without restarting the server",
> +                       item->errmsg = pstrdup("parameter cannot be
> changed without restarting the server");
>                         error = true;
>                         continue;

> Also, the above hunk is wrong, because the item variable is wobbly and
> the correspond line is not exists here.

er ... what?
        regards, tom lane