database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-25 21:42:33 +03:00
Code

doc Improve C GUC-related comments

Browse Source 
Discussion: https://postgr.es/m/CAEG8a3LZHTR5S+OPZCbZvECwsqdbx=pBRFZZyDjKaAtgoALOQQ@mail.gmail.com

Author: Junwang Zhao

Backpatch-through: master
This commit is contained in:
Bruce Momjian 2023-10-27 19:05:25 -04:00
parent a978565ffc
commit 12cf3ac7f3
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/backend/access/common/reloptions.c
View File

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