Make the set of reserved schemas and extensions configurable.#530
Make the set of reserved schemas and extensions configurable.#530ibrarahmad wants to merge 2 commits into
Conversation
Spock keeps certain schemas and extensions out of the structure synchronization dump, and forbids their tables from being added to a replication set. This set was fixed and could only be changed by rebuilding the extension, and the two behaviours were maintained independently, so they could drift apart. Keep the set in a catalog instead, seeded with the same defaults as before: spock and snowflake are both excluded from the dump and blocked from replication sets, while lolor is excluded from the dump but still allowed in replication sets so that large objects survive dropping the extension on every node. The seeded entries are protected and cannot be removed, and an operator can now reserve additional schemas or extensions without rebuilding. Such additions are preserved across dump and restore, while the built-in entries are always re-created.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughChangesReserved object catalog
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Duplication | 2 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
sql/spock--6.0.0.sql (1)
1-1: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winUpsert race in
reserved_object_add, duplicated in both scripts.The UPDATE-then-INSERT upsert has a TOCTOU window: concurrent first-time adds of the same
(name, kind)can both miss theUPDATEand race on theINSERT, surfacing a raw unique-violation instead of a clean upsert.ON CONFLICTis unusable here since the table isuser_catalog_table(PostgreSQL rejectsON CONFLICTon catalog-marked relations), but the race can be closed with a caught exception.
sql/spock--6.0.0.sql#L380-398: wrap theINSERTin anEXCEPTION WHEN unique_violationblock that falls back toUPDATE.sql/spock--5.0.10--6.0.0.sql#L396-414: apply the identical fix so the upgrade script matches the fresh-install script.🔒 Proposed fix (apply to both files)
IF NOT FOUND THEN - INSERT INTO spock.reserved_object - (name, kind, exclude_from_dump, block_in_repset, builtin) - VALUES (p_name, p_kind, p_exclude_from_dump, p_block_in_repset, false); + BEGIN + INSERT INTO spock.reserved_object + (name, kind, exclude_from_dump, block_in_repset, builtin) + VALUES (p_name, p_kind, p_exclude_from_dump, p_block_in_repset, false); + EXCEPTION WHEN unique_violation THEN + UPDATE spock.reserved_object + SET exclude_from_dump = p_exclude_from_dump, + block_in_repset = p_block_in_repset + WHERE name = p_name AND kind = p_kind; + END; END IF;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@sql/spock--6.0.0.sql` at line 1, Update the reserved_object_add implementation in both scripts by wrapping its INSERT path in an exception block that catches unique_violation and falls back to the existing UPDATE for the same name and kind. Keep the current update-then-insert behavior and apply the identical handling in both fresh-install and upgrade definitions.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/spock_functions/repset_mgmt.md`:
- Around line 362-367: Update the documented signature and parameter
descriptions for spock.reserved_object_remove to use the SQL-defined names
object_name and object_kind instead of p_name and p_kind, while preserving their
existing schema/extension meanings.
In `@sql/spock--5.0.10--6.0.0.sql`:
- Around line 396-414: Update spock.reserved_object_add to handle the concurrent
insert race: retain the existing UPDATE-first behavior, but wrap the INSERT in a
unique-violation exception handler and retry the UPDATE for the same (p_name,
p_kind) row when another call wins the insert. Preserve the current values and
builtin=false semantics without using ON CONFLICT.
---
Outside diff comments:
In `@sql/spock--6.0.0.sql`:
- Line 1: Update the reserved_object_add implementation in both scripts by
wrapping its INSERT path in an exception block that catches unique_violation and
falls back to the existing UPDATE for the same name and kind. Keep the current
update-then-insert behavior and apply the identical handling in both
fresh-install and upgrade definitions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 45fbe9d4-f9ed-46b2-a73a-84d171486cf2
📒 Files selected for processing (7)
docs/spock_functions/repset_mgmt.mdinclude/spock_node.hsql/spock--5.0.10--6.0.0.sqlsql/spock--6.0.0.sqlsrc/spock_node.csrc/spock_sync.ctests/tap/t/027_reserved_object.pl
Render the extension config table deterministically in the init test, make the reserved-object add helper upsert race-safe, and give its remove helper consistent parameter names.
susan-pgedge
left a comment
There was a problem hiding this comment.
The .md files look good to me - I can't speak for the .c/.sql/.pl files!
Spock keeps certain schemas and extensions out of the structure synchronization dump, and forbids their tables from being added to a replication set. This set was fixed and could only be changed by rebuilding the extension, and the two behaviours were maintained independently, so they could drift apart.
Keep the set in a catalog instead, seeded with the same defaults as before: spock and snowflake are both excluded from the dump and blocked from replication sets, while lolor is excluded from the dump but still allowed in replication sets so that large objects survive dropping the extension on every node. The seeded entries are protected and cannot be removed, and an operator can now reserve additional schemas or extensions without rebuilding. Such additions are preserved across dump and restore, while the built-in entries are always re-created.