From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_file_settings view vs. Windows |
Date: | 2015-06-29 14:42:50 |
Message-ID: | 4097.1435588970@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> writes:
> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So let me make a radical proposal that both gets rid of the portability
>> problem and, arguably, makes the view more useful than it is today.
>> I think we should define the view as showing, not what was in the config
>> file(s) at the last SIGHUP, but what is in the files *now*. That means
>> you could use it to validate edits before you attempt to apply them,
>> rather than having to pull the trigger and then ask if it worked. And yet
>> it would remain just about as useful as it is now for post-mortem checks
>> when a SIGHUP didn't do what you expected.
> You meant that we parse each GUC parameter in configration file, and
> then pass changeVal=false to set_config_option whenever
> pg_file_settings is refered.
> So this view would be used for checking whether currently
> configuration file is applied successfully or not, right?
Well, it would check whether the current contents of the file could be
applied successfully.
> The such a feature would be also good, but the main purpose of
> pg_file_settings was to resolve where each GUC parameter came from,
> especially in case of using ALTER SYSTEM command.
> I'm not sure that it would be adequate for our originally purpose.
I'm not following. Surely pg_settings itself is enough to tell you
where the currently-applied GUC value came from.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-06-29 15:27:38 | Reduce ProcArrayLock contention |
Previous Message | Simon Riggs | 2015-06-29 13:48:52 | Re: drop/truncate table sucks for large values of shared buffers |