I’ve called my father’s insulin pump customer support number once before and the medical advice they gave us would have endangered his life if I had carried it out (according to his GP, whom we called after to confirm).
"I will probably also be meaner to everyone who gets me on the phone in the future during an emergency. I was trying specifically to not do that, but I suppose it's helpful to be mean when your medical equipment is failing."
No, but it feels that way if you're an agreeable people-pleaser. (This is, of course, a bad habit, but it's a common one, and it's not one that merely acknowledging will divest you of.)
> Admittedly, I did have an opportunity to cause a fuss which I did not choose to take […]
> This was dumb of me. I should have caused a bigger fuss. If I'd bitched to more people and made more phone calls and […]
> So I escaped this extremely risky and stupid problem - partially of the pump's making, partially of my own creation - with zero consequences other than the fact […]
> I hope that you can understand why - even when I made the situation worse by not throwing a big enough fit - I held in my heart […]
The blog post says things other than "this was all my fault" (which, channelling Nancy G. Leveson, is not something we should ever say about the failure of a complex system), but it does very much say what you say it should say. The vast majority of the "mean things" in this blog post are polite descriptions of the facts; the remainder are rather mild expressions of frustration, plus one death wish against a hypothetical someone exhibiting an extremely obnoxious communication behaviour.
lol, i think the LLM shows more wisdom here than the average person. Functionally, being 50m away from the car wash is at the car wash if you have a dirty car in your possession that needs cleaning. Realistically, the only reason you express the need to go to the carwash if you are in a 50m proximity with your car you intend to clean at the carwash is if you need to walk in and talk to someone.
I think the point is that it is his OPs opinion and they cannot read the future. Nobody here can, so the reply has just as much weight as the original.
So saving and living below means is a great strategy either way.
Even better: optional book comes with a code you can use to register to an electronic version of the exam. Of course you can do it on pen and paper separate from most of the class if you don’t want to buy it…
"a database which uses optimistic concurrency in serializable isolation level. Postgres is often configured this way, though it's not the only way it can be configured."
It's not the default (read committed is) and I never saw serializable being set in actual production systems. You can do it, but then you have to be able to retry all of your transactions, including read.
What if the task you do take 5 minutes? 30 minutes? 10 hours? Do you create long transaction, blocking all reads?
> It's not the default (read committed is) and I never saw serializable being set in actual production systems.
It's not the common mode of deployment, but it's definitely in prod use.
> You can do it, but then you have to be able to retry all of your transactions, including read.
Pure read transactions shouldn't need to be retried in postgres due to serialization errors. You need to have read-write dependencies for that.
That's not to say that effectively read only transactions aren't affected by serializable, you do need to record the necessary metadata for the serialization logic to work.
FWIW, if you know your transaction is read only and long running, you can start a transaction with START TRANSACTION READ ONLY DEFERRABLE, which makes the start transaction slower, but then does not need to do any work related to serializable while the transaction is running.
> I never saw serializable being set in actual production systems
Every major prod system I've worked on in the last 15 years ran in serializable, including my current charge which processes tens of billions of dollars annually. YMMV but this is quite common in serious production systems. Google's Spanner only runs in serializable.
It doesn't matter though. I could write the sequence out with a SELECT FOR UPDATE and the second request will block instead of retry. The client experience is the same; the "second" request blocks. @pdonis wanted an example so I picked one.
It's just the horrible misapplication of the term 'stateless' to a wrapper around something very-much stateful. It's here to stay.
(Though I do disagree with the original premise too. Putting on a 'stateless' boxing glove won't mean there's no difference between punching a guy once or twice)
reply