-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
proj, postgres, spring, fork, Big Sur faulting #18
Comments
We have discovered that if we exercise our Factory early in the test process, then we can at least run tests using
|
Perhaps final followup. Following this:
Then:
And when Factory is warmed up as above, only then |
Thanks for the detailed write-up. I don't know how much I'll be able to help as more info comes out about the root cause since I don't have access to a system with an M1 chip. If there's anything I can do or if you want to ask questions/discuss something about how the library is set up that might be causing it I'd be happy to help. |
Thanks for the offer. Thought we had things resolved but we're still getting raise errors on rails 6.1 in some scenarios. If we can leave this open for a bit I'll add further insights if/when we track them down. There is an outside chance it's related to table truncation/forking, but not worth sending people off on wild goose chases till we can nail things down further. |
Spamming keywords to others might find this. I realize this this is
spring
centric, but there is high potential for some pg element to it, see below. This issue is, maybe, alluded to in various other tickets in various other places, none of which seem to come up with a concrete answer, crossreferencing:When we run
spring
then we get faults on both M1 and Intel under Big Sur.proj_create_operations: SQLite error on SELECT allowed_authorities FROM authority_to_authority_preference WHERE source_auth_name = ? AND target_auth_name = ?: disk I/O error
1
2
The text was updated successfully, but these errors were encountered: