|
42 | 42 | * |
43 | 43 | * To add an option: |
44 | 44 | * |
45 | | - * (i) decide on a type (integer, real, bool, string), name, default value, |
46 | | - * upper and lower bounds (if applicable); for strings, consider a validation |
47 | | - * routine. |
| 45 | + * (i) decide on a type (bool, integer, real, enum, string), name, default |
| 46 | + * value, upper and lower bounds (if applicable); for strings, consider a |
| 47 | + * validation routine. |
48 | 48 | * (ii) add a record below (or use add_<type>_reloption). |
49 | 49 | * (iii) add it to the appropriate options struct (perhaps StdRdOptions) |
50 | 50 | * (iv) add it to the appropriate handling routine (perhaps |
|
68 | 68 | * since they are only used by the AV procs and don't change anything |
69 | 69 | * currently executing. |
70 | 70 | * |
71 | | - * Fillfactor can be set because it applies only to subsequent changes made to |
72 | | - * data blocks, as documented in hio.c |
| 71 | + * Fillfactor can be set at ShareUpdateExclusiveLock because it applies only to |
| 72 | + * subsequent changes made to data blocks, as documented in hio.c |
73 | 73 | * |
74 | 74 | * n_distinct options can be set at ShareUpdateExclusiveLock because they |
75 | 75 | * are only used during ANALYZE, which uses a ShareUpdateExclusiveLock, |
76 | 76 | * so the ANALYZE will not be affected by in-flight changes. Changing those |
77 | 77 | * values has no effect until the next ANALYZE, so no need for stronger lock. |
78 | 78 | * |
79 | | - * Planner-related parameters can be set with ShareUpdateExclusiveLock because |
| 79 | + * Planner-related parameters can be set at ShareUpdateExclusiveLock because |
80 | 80 | * they only affect planning and not the correctness of the execution. Plans |
81 | 81 | * cannot be changed in mid-flight, so changes here could not easily result in |
82 | 82 | * new improved plans in any case. So we allow existing queries to continue |
83 | 83 | * and existing plans to survive, a small price to pay for allowing better |
84 | 84 | * plans to be introduced concurrently without interfering with users. |
85 | 85 | * |
86 | | - * Setting parallel_workers is safe, since it acts the same as |
87 | | - * max_parallel_workers_per_gather which is a USERSET parameter that doesn't |
88 | | - * affect existing plans or queries. |
| 86 | + * Setting parallel_workers at ShareUpdateExclusiveLock is safe, since it acts |
| 87 | + * the same as max_parallel_workers_per_gather which is a USERSET parameter |
| 88 | + * that doesn't affect existing plans or queries. |
89 | 89 | * |
90 | 90 | * vacuum_truncate can be set at ShareUpdateExclusiveLock because it |
91 | 91 | * is only used during VACUUM, which uses a ShareUpdateExclusiveLock, |
|
0 commit comments