Prevent app crash when postgres prepared query keys become out of sync with Rails #41356
Increment @counter of prepared postgres statements prior to running the query, so if the query gets interrupted without Rails' knowledge we don't end up with a crashed app in a state of perpetual failure to prepare the next query.
Based on this PR #41034 , thanks wbharding, I only streamlined the change and added a test.
Any suggestions on improving the test welcome! My first time digging into the Rails (test-)code base.
The text was updated successfully, but these errors were encountered:
…he query. If the next query or the prepared statement itself get interrupted, this prevents the database session getting stuck perpetually retrying to recreate the same prepared statement.
I feel really sad that my efforts in the linked PR were ignored for 5 years even with lots of supporters, for what was in my opinion petty bikeshedding, yet this PR here that does essentially the same thing but differently, got the go ahead really quickly. This decision feels to me like it was politically motivated more than anything.
It certainly does not encourage me to contribute to Rails any longer.
Yes. This PR had a different perspective about the problem and which cases the system could be failing.
Before the argument was about rack-timeout and
Now it was about
Compared with the timeframe of your PR, yes, it is true that it was quick, but I was considering this change since #41034, in the beginning still skeptical about it.
New arguments are introduced to discussions, the code evolve, we evolve, our decision evolve.
I'm sorry that you feel that way, it wasn't my intention to discourage you from contributing to the framework
I still don't understand the hostile environment argument, how is making a timeout not break an entire app accounting for a hostile environment? If you have code that prevents all timeouts please share it with the rails community. How is one exception raised in the context of a single request breaking an entire application acceptable? By your logic we should just have a rack timeout
The fact that you can DDoS a rails app by making requests hang and timeout until the prepared statement issue happens seems like a security issue IMO
I think it's stubborn and short sighted to skip over a simple and elegant solution from @dv