Yesterday we migrated many #postgresql databases to 16.2. It went smoothly for all of them except one.
The database is used by Sidekiq for 90% of the traffic. We choose a time window outside of working hours, but still we had some traffic, and we didn't turn off pods. The database was inaccessible for 10min. Jobs rescheduled, and quickly auto-scaling was triggered. I was not able to perform ANALYZE. So requests retrying at the same time + huge disk read. 💥
Don't get me wrong, my experience told me is usually not a good idea to rely on managed databases that much, if I had full control of the servers then it may be fine, we can do dry-runs multiple times and monitor before proceeding.
When I do not have control of the #postgresql server I prefer to follow what Heroku have documented:
@tekin@benoit +1 this, if you want to pass a module as a callable this is ok [but why do you need a module as a callable], the instance then is a bit weird but if you need to make things "private” I guess its... fine
@JonRowe@tekin@benoit I must admit this is pattern I use a lot - though using Ruby's ellipsis for argument forwarding - and yes, for classes that perform a single action.
I find it removes needing to think about how to invoke the action (i.e. should it be .create, .save, .send? Less confusion, just always use .call).
And it’s the same interface for invoking procs (a use-case for which .new().call doesn't fit), so I can pass callable objects (proc, class, or instance) as arguments.
I observe devs in my company bringing back the "schema.rb" file from production into the Git repository.
I am uncertain about this practice. Modifying directly the schema.rb file has consistently been problematic for me. Perhaps it's less of an issue if you solely use schema:load, but I remain skeptical.
I would prefer a re-entering migration to rectify the schema, such as using 'create index if not exists.' This way, changes are propagated across all databases in various environments.
@byroot@benoit I live in slight fear that our schema.rb does not actually match our production schema, even though theoretically it should. So this sort of back porting it from production is attractive at least as a sanity/anxiety check
@benoit That is true across all programming communities. My answer to this is that people feel far more natural to ask help to their community than to ask to a bloody broken machine.
It's interesting to see the discussions on the Twitter or elsewhere about the new gems that will probably be default soon in Rails and already existing OSS contributors that do similar things since multiple years.
I am wondering how those new librairies could benefit virtuously from the previous one:
Hiring partially previous maintainer to work on the new one?
Cleary extract concept and refere to previous implementation if maintainer and licence is ✅
@benoit I'm a big fan of projects that include an "Other libraries" / "Inspiration" section in their readme. It doesn't cost anything to acknowledge the existing projects, it helps users find the library that's right for them and fosters a sense of community.
The last 2 week were full of SQL and PostgreSQL RDS. Sometimes it was difficult but always very interesting. I learn a lot and I really love the community and this piece of technology.
Still some frustrations but at least I know some caveats about the #postgresql.
We had also a big freeze on one of our DB after an upgrade. We had to do a full analyze, then kill queries that were waiting because of BufferIO or DataFileRead.
We didn't understand what happen. Bad statistic? Query that block I/O 🤷
Les priorités à droite en agglomération, encore une idée qui devrait disparaître pour permettre aux enfants de plus prendre la route.
Je comprendrais jamais ces économies de panneaux, alors que tous les mois ces carrefours sont des sources d'accidents.