Re: Semantics of pg_file_settings view

Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> writes:
> On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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