On 14 September 2016 at 14:48, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Sep 1, 2016 at 9:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> > Can I change this to a lower setting? I would have done this before
>>>> > applying
>>>> > the patch, but you beat me to it.
>>>>
>>>> I don't have a problem with reducing the lock level there, if we're
>>>> convinced that it's safe.
>>>
>>>
>>> I'll run up a patch, with appropriate comments.
>>
>> Attached
>
> This should really be posted on a new thread, since it changes a bunch
> of reloptions, not only parallel_workers. I can't immediately think
> of a reason why the changes wouldn't be safe, but I've failed to fully
> apprehend all of the possible dangers multiple times previously, so we
> should try to give everyone who might have ideas about this topic a
> chance to chime in with anything we might be missing.
OK. Will post on new thread.
> I do think this comment is confusing:
>
> + * This value is not locked by the transaction, so this value may
> + * be changed while a SELECT that has used these values for planning
> + * is still executing.
>
> I don't know what it means for "this value" to be locked, or not
> locked, by the transaction. Basically, I have no idea what this is
> trying to explain.
You're quoting that without context from the line above, which is
"get_tablespace_io_concurrency"
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services