Change readonly parameter values in documentation#375
Change readonly parameter values in documentation#375zaidshabbir25 wants to merge 1 commit intomainfrom
Conversation
Updated the documentation to reflect changes in the readonly parameter values.
📝 WalkthroughWalkthroughDocumentation for the spock.readonly setting is updated to replace 'on' with 'all' in ALTER SYSTEM and SET command examples. The available values for the setting are now explicitly documented as off, user, and all. Status query functionality remains unchanged. Changes
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/managing/read_only.md`:
- Line 48: Update the docs to reflect the three-mode semantics implemented in
code: replace binary "on/off" language with the modes "off, user, all" and
describe that spock_readonly (the configuration variable) comparisons use
READONLY_USER to block non-readonly statements for all non-superuser exemptions
removed—i.e., when spock_readonly >= READONLY_USER regular sessions are
prevented from executing non-readonly statements—and that the only distinction
for replication is in spock_apply.c where READONLY_ALL additionally blocks
replication apply; reference spock_readonly, READONLY_USER, READONLY_ALL,
spock_readonly.c, and spock_apply.c so the doc text matches enforcement.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fadf753d-118b-44ab-bc73-003f75e777d0
📒 Files selected for processing (1)
docs/managing/read_only.md
| - When the cluster is in read-only mode, only non-superusers are restricted to read-only operations. Superusers can continue to perform both read and write operations. | ||
| - By using a GUC parameter, you can easily manage the cluster's read-only status through standard PostgreSQL configuration mechanisms. | ||
|
|
||
| - Available values for readonly are: off, user, all |
There was a problem hiding this comment.
Behavior docs are now internally inconsistent after adding off, user, all.
After introducing three modes, nearby text still describes binary on/off output (Line 42) and says superusers are exempt (Lines 3/21/46). That does not match enforcement in src/spock_readonly.c:62-96 (spock_readonly >= READONLY_USER blocks non-read-only statements regardless of role) and the only user vs all distinction appears in replication apply (src/spock_apply.c:2407-2425, where all blocks apply). Please update the behavior description in this doc section to reflect actual mode semantics.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/managing/read_only.md` at line 48, Update the docs to reflect the
three-mode semantics implemented in code: replace binary "on/off" language with
the modes "off, user, all" and describe that spock_readonly (the configuration
variable) comparisons use READONLY_USER to block non-readonly statements for all
non-superuser exemptions removed—i.e., when spock_readonly >= READONLY_USER
regular sessions are prevented from executing non-readonly statements—and that
the only distinction for replication is in spock_apply.c where READONLY_ALL
additionally blocks replication apply; reference spock_readonly, READONLY_USER,
READONLY_ALL, spock_readonly.c, and spock_apply.c so the doc text matches
enforcement.
1 participant
Updated the documentation to reflect changes in the readonly parameter values.