In-memory db support incomplete #44
Assignees
Comments
|
This oughta do the trick: penumbra-zone/penumbra#2519 |
|
Upstream PR is merged. We expect that re-deploy of Galileo as part of Testnet 52 (penumbra-zone/penumbra#2415) will Just Work™ with in-memory db now. Leaving this open to confirm post-deploy. |
conorsch
added a commit
that referenced
this issue
May 12, 2023
conorsch
added a commit
that referenced
this issue
May 12, 2023
* fix: update broadcast_transaction sig Corresponds to changes in penumbra-zone/penumbra@6705d93 * lint: remove unused view_file Refs #44 --------- Co-authored-by: Conor Schaefer <conor@penumbralabs.xyz>
|
Galileo has been running smoothly on 52, using the latest in-memory db logic. 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #43 we opted-in to using an in-memory db for galileo, so it doesn't need to rely on a filepath for the pcli db. That's rad, and we're excited to use it. We're not using it yet though, since we merged that PR right after Testnet 51 went out (technically after v0.51.2, which was a bumpy ride). Just checked, and Galileo is currently running off commit 9cf69ef.
During a debugging pairing session on Osiris, which reuses a fair amount of Galileo code, we observed some surprising behavior related to the in-memory database. Our current strategy is to limit the connection pool to 1 if-and-only-if we're using in-memory db. We should make the corresponding change to Galileo, too, or else revert to using the on-disk db.
The text was updated successfully, but these errors were encountered: