On 14 September 2016 at 14:48, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Sep 1, 2016 at 9:39 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
