* Add Accountsdb plugin documentations (#21746)
Add the public facing documentation about the plugin framework: explaining the interface, how to load plugin and the example PostgreSQL plugin implementation.
Updated the rust documentation for the plugin interfaces for accounts and slot.
This changes are targeted for v1.8. Information about transactions will be updated later.
* fmt issue
* SDK: Add stdlib.h include to pull in `abort()` (#21700)
(cherry picked from commit 923720f529)
# Conflicts:
# sdk/bpf/c/inc/sol/assert.h
* Fix merge conflict
Co-authored-by: Jon Cinque <jon.cinque@gmail.com>
* adds back position field to coding-shred-header (#21600)
https://github.com/solana-labs/solana/pull/17004
removed position field from coding-shred-header because as it stands the
field is redundant and unused.
However, with the upcoming changes to erasure coding schema this field
will no longer be redundant and needs to be populated.
(cherry picked from commit cd17f63d81)
# Conflicts:
# core/src/window_service.rs
# ledger/src/blockstore.rs
# ledger/src/shred.rs
* removes backport merge conflicts
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
- Adds feature reject_section_virtual_address_file_offset_mismatch.
- Adds feature start_verify_shift32_imm.
- Enables enable_symbol_and_section_labels only in the rbpf-cli.
* Moves syscall_registry into the rbpf Executable constructor.
* Adds the reject_unresolved_syscalls flag which is only set when deploying programs via the CLI.
* Ledger-tool: only require ledger dir when necessary (#21575)
* Don't canonicalize ledger_path unless ledger_path will be used
* Single use statement
(cherry picked from commit 2b269dbe0e)
# Conflicts:
# ledger-tool/src/main.rs
* Fix conflicts
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
Co-authored-by: Tyera Eulberg <tyera@solana.com>
Otherwise getHealth fails if account hashes are not propagated.
(cherry picked from commit 9886366977)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
For writing tests, it is often desirable to create a certain situation
that would be tedious, or even impossible to create by sending
individual transactions.
For example, a common attack vector on Solana is to create a copy of
some existing account that stores configuration data, but manipulate the
data stored there, and then to call a program and pass in the
manipulated account, instead of the real account.
If one wants to test this, one option is to write a program that you can
call to write arbitrary data into a new account account (and possibly
change its owner), then include that program in the test context, and
send a transaction to call it. This is extremely tedious, and developers
are not going to bother doing it. I myself would rather fork
solana-program-test to add this `set_account` method, than to write that
program. Having a “god mode” method to just write an account, lowers the
barrier to writing comprehensive tests.
A second reason for introducing this method, is defense in depth. There
may be states of the bank that are not reachable *yet* by only sending
transactions, but that you might want to test against either way. For
example, right now, the balance of a stake account cannot decrease
without going through the stake program. But what if Solana were to
introduce slashing in the future, and you want to ensure your program is
robust against decreases in stake account balance? Right now there is no
way to test this, but by introducing this “god mode” to write accounts,
the situation becomes testable.
(cherry picked from commit e7fa412465)
