-
Notifications
You must be signed in to change notification settings - Fork 11.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ConsensusV2 object support to sui-indexer{,alt}
#20486
Conversation
Updates `sum_coin_balances` and `wal_coin_balances` tables to add a column for `owner_kind`, so that balances can be tracked separately for address-owned vs. consensus coins.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on what I understood of the plan, we want to treat objects and coins slightly differently when it comes to consensus-management (in that we want to abstract it away for objects, and not for coins), which will require some minor changes, but the sketch is there, thanks @aschran !
crates/sui-indexer-alt/migrations/2024-10-28-144002_sum_coin_balances/up.sql
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,6 @@ | |||
ALTER TABLE sum_coin_balances | |||
ADD COLUMN owner_kind SMALLINT NOT NULL DEFAULT 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we have switched over to a version of the indexer that knows about this column, we should come back and drop the DEFAULT
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we are going to need to update all the indices on all these tables -- wherever they mentioned owner_id
we now need to prefix it with an owner_kind
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added index updates
@@ -99,8 +99,7 @@ impl Processor for SumObjTypes { | |||
Owner::ObjectOwner(_) => StoredOwnerKind::Object, | |||
Owner::Shared { .. } => StoredOwnerKind::Shared, | |||
Owner::Immutable => StoredOwnerKind::Immutable, | |||
// TODO: Implement support for ConsensusV2 objects. | |||
Owner::ConsensusV2 { .. } => todo!(), | |||
Owner::ConsensusV2 { .. } => StoredOwnerKind::ConsensusV2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that for objects we wanted to treat consensus-owned objects as address-owned if they the authenticator maps to a single address, which means no new kind here. (Then there was a future question of how we handle party objects which we kind of punted on, but the options varied from treating them like shared objects, to having some separate category for jointly-owned objects).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated as per huddle
// ConsensusV2 objects are treated as address-owned for now in indexers. | ||
// This will need to be updated if additional Authenticators are added. | ||
Owner::ConsensusV2 { authenticator, .. } => ( | ||
StoredOwnerKind::ConsensusV2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use a different enum here to the one we use for objects in general, because while we don't want to distinguish consensus-managed single-owned objects from address-owned objects, we do want to do that for coins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
created a new enum
// This will need to be updated if additional Authenticators are added. | ||
Owner::ConsensusV2 { authenticator, .. } => ( | ||
StoredOwnerKind::ConsensusV2, | ||
authenticator.as_single_owner(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noting my momentary confusion that this doesn't return an Option<...>
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, i put a comment on the function to clarify in another PR
There is now also a obj_info pipeline |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change now looks good to me! cc @lxfind though as he is currently working on the sum_coin_balances
and sum_obj_types
pipelines (or their equivalents), so we may need to incorporate changes there.
I've also left a comment on how to make the index changes go through smoothly. Once those changes are in, we can coordinate the land and proactively running the migration so everything keeps working smoothly.
DROP INDEX sum_coin_balances_owner_type; | ||
CREATE INDEX sum_coin_balances_owner_type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking of some ways to make this easier to land without causing the indexer to hang when it starts, and I think I have an idea:
- We can get postgres to drop and create these indices concurrently, which will mean they won't hang other things that are going on at the same time (this will allow us to run the migrations proactively while the indexer is running),
- and then turn them into
IF EXISTS
/IF NOT EXISTS
style statements so that they become idempotent, (which means after we've run it proactively, when the migration runs, it knows not to drop and regenerate the indices), - and finally, we need to give the new index a new name so that
IF EXISTS
/IF NOT EXISTS
would recognise it as different from the old index.
The statements for creating and dropping the indices would look like this then:
DROP INDEX sum_coin_balances_owner_type; | |
CREATE INDEX sum_coin_balances_owner_type | |
DROP INDEX CONCURRENTLY IF EXISTS sum_coin_balances_owner_type; | |
CREATE INDEX CONCURRENTLY IF NOT EXISTS sum_coin_balances_owner_kind_owner_id_type; |
But you will also need to split it up over separate migration scripts (because each script is its own transaction and postgres won't like it if you combine non-blocking concurrent operations with other work in a transaction). I've had to do this once before in #19543 so that can serve as a template (there's an extra TOML file that needs to go in each migration folder to tell diesel to not batch up migrations into a transaction as well).
(ditto for the wal tables below).
EDIT: tweaked index name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this, let me know if it looks correct. when I run generate_schema.sh
locally it fails with an error
2024-12-05 10:37:44.702 EST [78369] ERROR: DROP INDEX CONCURRENTLY cannot run inside a transaction block
But I have the metadata.toml
files there as you suggested - is anything else missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is that the migrations need to be split up even further -- each DROP INDEX
and CREATE INDEX
needs to be in their own script (because they can't mingle with each other either).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Description Partial revert of #20486 (only the changes relevant to `sui-indexer-alt`), as the migrations associated with that change are taking too long to run on the production database. We will have to revisit how to set-up those migrations so that they run in a reasonable time. ## Test plan Local run of `sui-indexer-alt` + CI.
…20546) ## Description Partial revert of #20486 (only the changes relevant to `sui-indexer-alt`), as the migrations associated with that change are taking too long to run on the production database. We will have to revisit how to set-up those migrations so that they run in a reasonable time. ## Test plan Local run of `sui-indexer-alt` + CI. --- ## Release notes Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required. For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:
Updates
sum_coin_balances
andwal_coin_balances
tables to add a column forcoin_owner_kind
, so that balances can be tracked separately for fastpath vs. consensus coins.Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.
coin_owner_kind
column to coin balances tables.