On Tue, Jan 21, 2020 at 07:27:47PM -0600, Justin Pryzby wrote: > Attached minimal patch with just this hunk. > > https://commitfest.postgresql.org/27/2417/ > => RFC
I think that you should be more careful when you think that you create a new thread. On my client for example, I can see that this message is part of its last thread and still holds references to the previous thread. My guess is that as you are using gmail you just changed the subject, thinking that it actually created a new thread. > @@ -714,9 +714,7 @@ WITH ( MODULUS <replaceable > class="parameter">numeric_literal</replaceable>, REM > <para> > <literal>SHARE UPDATE EXCLUSIVE</literal> lock will be taken for > fillfactor, toast and autovacuum storage parameters, as well as the > - following planner related parameters: > - <varname>effective_io_concurrency</varname>, > <varname>parallel_workers</varname>, <varname>seq_page_cost</varname>, > - <varname>random_page_cost</varname>, <varname>n_distinct</varname> and > <varname>n_distinct_inherited</varname>. > + <varname>parallel_workers</varname> planner parameter. Right. n_distinct_inherited and n_distinct can only be set for attribute, and the docs are clear about that. effective_io_concurrency, seq_page_cost and random_page_cost apply to a tablespace. There is one other thing that this this paragraph misses though: vacuum_index_cleanup is a parameter dedicated to vacuum, and not autovacuum. So to be clear I think that the first sentence should mention "vacuum" as much as "autovacuum" in the list of storage parameter types impacted by the lower-level lock taken. -- Michael
signature.asc
Description: PGP signature