Conversation
|
Warning Review limit reached
More reviews will be available in 41 minutes and 55 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. 📝 WalkthroughWalkthroughThe pull request removes the ChangesSchema skip list update
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 | 0 |
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.
…tion We can't automatically add an arbitrary extension's objects into a subscription (but can try to do this for LOLOR solely). So, manual addition stands. But anyway, initial Spock sync should copy LOs to replica.
Summary
Spock keeps two static deny-lists,
skip_schemaandskip_extension(src/spock_node.c), that name schemas and extensions whose relations are never replicated. Any object in those lists is rejected from replication sets byEnsureRelationNotIgnored(), and is excluded from the initial subscription sync via--exclude-schema/--exclude-extensionflags passed topg_dump(build_exclude_schema_string()/build_exclude_extension_string()insrc/spock_sync.c).lolorwas wrongly listed in both arrays. That directly contradicts the purpose of the LOLOR extension: it relocates large objects out of the catalog into ordinary tables (lolor.pg_largeobject,lolor.pg_largeobject_metadata) precisely so they can be logically replicated, and the lolor docs instruct users to add those tables to their replication set. With lolor on the deny-lists, that documented step failed and large objects were silently skipped during initial sync.This change removes
"lolor"from bothskip_schemaandskip_extension.Effect
EnsureRelationNotIgnored()no longer rejectslolor.pg_largeobjectandlolor.pg_largeobject_metadatawhen they are added to a replication set, so the documentedrepset-add-tableworkflow now works.--exclude-schema=lolor/--exclude-extension=lolortopg_dump, so existing large objects are copied to the replica.Notes
We cannot automatically add an arbitrary extension's objects to a subscription, so manual addition of the two lolor tables to the replication set still stands as the supported workflow.
snowflakeandspockremain on the deny-lists; onlyloloris removed.