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: * To add an option:
* *
* (i) decide on a type (integer, real, bool, string), name, default value, * (i) decide on a type (bool, integer, real, enum, string), name, default
* upper and lower bounds (if applicable); for strings, consider a validation * value, upper and lower bounds (if applicable); for strings, consider a
* routine. * validation routine.
* (ii) add a record below (or use add_<type>_reloption). * (ii) add a record below (or use add_<type>_reloption).
* (iii) add it to the appropriate options struct (perhaps StdRdOptions) * (iii) add it to the appropriate options struct (perhaps StdRdOptions)
* (iv) add it to the appropriate handling routine (perhaps * (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 * since they are only used by the AV procs and don't change anything
* currently executing. * currently executing.
* *
* Fillfactor can be set because it applies only to subsequent changes made to * Fillfactor can be set at ShareUpdateExclusiveLock because it applies only to
* data blocks, as documented in hio.c * subsequent changes made to data blocks, as documented in hio.c
* *
* n_distinct options can be set at ShareUpdateExclusiveLock because they * n_distinct options can be set at ShareUpdateExclusiveLock because they
* are only used during ANALYZE, which uses a ShareUpdateExclusiveLock, * are only used during ANALYZE, which uses a ShareUpdateExclusiveLock,
* so the ANALYZE will not be affected by in-flight changes. Changing those * 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. * 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 * 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 * 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 * 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 * and existing plans to survive, a small price to pay for allowing better
* plans to be introduced concurrently without interfering with users. * plans to be introduced concurrently without interfering with users.
* *
* Setting parallel_workers is safe, since it acts the same as * Setting parallel_workers at ShareUpdateExclusiveLock is safe, since it acts
* max_parallel_workers_per_gather which is a USERSET parameter that doesn't * the same as max_parallel_workers_per_gather which is a USERSET parameter
* affect existing plans or queries. * that doesn't affect existing plans or queries.
* *
* vacuum_truncate can be set at ShareUpdateExclusiveLock because it * vacuum_truncate can be set at ShareUpdateExclusiveLock because it
* is only used during VACUUM, which uses a ShareUpdateExclusiveLock, * is only used during VACUUM, which uses a ShareUpdateExclusiveLock,