commit 6f3a13ff058f15d565a30c16c0c2cb14cc994e42 Enhance docs for ALTER TABLE lock levels of storage parms Author: Simon Riggs <simon@2ndQuadrant.com> Date: Mon Mar 6 16:48:12 2017 +0530
<varlistentry> <term><literal>SET ( <replaceable class="PARAMETER">storage_parameter</replaceable> = <replaceable class="PARAMETER">value</replaceable> [, ... ] )</literal></term> ... - Changing fillfactor and autovacuum storage parameters acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> lock. + <literal>SHARE UPDATE EXCLUSIVE</literal> lock will be taken for + fillfactor and autovacuum storage parameters, as well as the + following planner related parameters: + effective_io_concurrency, parallel_workers, seq_page_cost + random_page_cost, n_distinct and n_distinct_inherited.
effective_io_concurrency, seq_page_cost and random_page_cost cannot be set for a table - reloptions.c shows that they've always been RELOPT_KIND_TABLESPACE.
Right, but if they were settable at table-level, the lock levels shown would be accurate.
I agree with the sentiment of the third doc change, but your patch removes the mention of n_distinct, which isn't appropriate.
The second change in your patch alters the meaning of the sentence in a way that is counter to the first change. The name of these parameters is "Storage Parameters" (in various places); I might agree with describing them in text as "storage or planner parameters", but if you do that you can't then just refer to "storage parameters" later, because if you do it implies that planner parameters operate differently to storage parameters, which they don't.
n_distinct lock mode seems to have been changed and documented at e5550d5f ; 21d4e2e2 claimed to do the same, but the LOCKMODE is never used.
But neither does it need to because we don't lock tablespaces.
