As `Range` is a special case of an `Iterator`, this is a generalization
that makes `get_all_accounts()` accept other kinds of ranges. Such as
`RangeInclusive`.
#### Problem
The existing append_accounts returns a vector of offsets, which accounts-db
later uses it to infer the storage size of each account. However, such inference
does not apply to the new hot/cold storage format.
#### Summary of Changes
This PR changes the return value of append_accounts() to `Vec<StoredAccountInfo>`,
which includes both offset and storage size information of an account.
* support loading snapshots with > 1 append vec per slot
* pr feedback
* drain to into_values
* unwrap() -> expect()
* loop to find non-conflicting file and add test
* Add helper function to create BlockstoreOptions from ValidatorConfig
* Make backup_and_clear_blockstore() honor ValidatorConfig options
backup_and_clear_blockstore() opens a Blockstore session; however, it
is currently using Blockstore::open(). This Blockstore method uses
BlockstoreOption::default() under the hood. As a result, any validator
args that adjust Blockstore settings are not considered in
backup_and_clear_blockstore().
This is especially problematic if the non-default value of
--rocksdb-shred-compaction is being used. In this case,
backup_and_clear_blockstore() was opening the wrong directory and
incorrectly finding an empty ledger.
This change plumbs any blockstore configuration to
backup_and_clear_blockstore().
https://github.com/solana-labs/solana/pull/26070
introduced MAX_CODE_SHREDS_PER_SLOT which because of how coding shreds
are generated was later set larger than MAX_DATA_SHREDS_PER_SLOT.
The old code was discarding: index >= MAX_DATA_SHREDS_PER_SLOT
regardless of if the shred is code or data:
https://github.com/solana-labs/solana/blob/v1.13.6/core/src/window_service.rs#L193-L195
Since that many code (or data) shreds will probably never result in a
rooted slot anyways, the commit reduces MAX_CODE_SHREDS_PER_SLOT to what
previously was the effective limit.
All the references returned from a `StoredAccountMeta` instance
actually come from the underlying account. As written, the lifetimes of
the returned references are constrained by the lifetime of the
`StoredAccountMeta` instance.
While technically correct, it is overly strict. It is totally fine to
use the returned reference as long as the underlying account is alive.
Which could be longer than the lifetime of the `StoredAccountMeta`
wrapper.
The print command looks up program_ids from transactions by creating
SanitizedTransactions. But, print doesn't have access to a Bank so
transactions that include an address table lookup can't be sanitized.
Sanitizing the transaction isn't necessary, so this change just looks up
the program id from unsanitized transactions.
* Move AdminRpcRequestMetadataPostInit to solana-core
* Move AdminRpcRequestMetadataPostInit write to just before wait_for_supermajority
* Pass AdminRpcRequestMetadataPostInit in TestValidatorGenesis
* Fixup local-cluster
This PR makes all the StoredAccountMeta fields pub(crate)
and provides getter functions to access its member fields.
This PR is a preparation step for abstracting out StoredAccountMeta.
the existing deserialize implementation overruns the sbf stack and is unusable in a program context
this silences a warning to that effect which all solana_program importers receive
closes#30188
Jon Cinque
Dmitri Makarov
Jeff Biseda
Will Hickey
HaoranYi
mvines
kirill lykov
K-anon
Brooks
Illia Bobyr
Yueh-Hsuan Chiang
Andrew Fitzgerald
Alexander Meißner
Jeff Washington (jwash)
Oliver Tušla
steviez
behzad nouri
sakridge
Yihau Chen
Tyera
Trent Nelson
Ikko Eltociear Ashimine
Jordan Sexton
hana
Tao Zhu