Sawada Masahiko <sawada.m...@gmail.com> writes:
> On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
