Propagate original callstack, save a fiber allocation if unnecessary #503
Conversation
| @@ -68,7 +68,7 @@ module Granite::Transactions | |||
| end | |||
| {% end %} | |||
| rescue err | |||
| raise DB::Error.new(err.message) | |||
| raise DB::Error.new(err.message, cause: err) | |||
There was a problem hiding this comment.
These were originally swallowing the underlying callstacks and only propagating the cannot allocate memory error message. Adding cause let me find where the root of the problem is (not the why, though, hrm).
| @@ -51,6 +51,8 @@ module Granite::ConnectionManagement | |||
| end | |||
|
|
|||
| def self.schedule_adapter_switch | |||
| return if @@writer_adapter == @@reader_adapter | |||
There was a problem hiding this comment.
Not making a spawn call here saves ~8mb of memory allocation due to a fiber stack allocation, and saves me from my problem (and I'm hoping saves others from unnecessary memory allocation as well).
|
An additional thought: I've been running into this I'm wondering if during the |
I'm working on a project that's generating a couple million rows to enter into a sqlite database. For reasons I haven't figured out yet, I'm getting a "cannot allocate memory" error when a new
spawncall is being made (I've verified the machine this program is running on has plenty of memory and isn't getting anywhere near the limit, and other fiber allocations seem to be working just fine 馃し ). Regardless of the what's causing that, I was able to update some error propagation in granite to discover an unnecessaryspawncall being made in the event the@@reader_adapterand@@writer_adapterare the same adapter. Making this PR to include the error propagation changes as well as fixing the unnecessaryspawncall.