It was shared on GitHub on Sunday July 22 by lemmy.ca staff. Developers who run the project do not seem to do merges on Saturday and Sunday. I submitted a pull request Sunday evening given the server crash relief this would provide, ready for them first thing Monday. I clearly labeled the pull request as “emergency”.
It is well into Wednesday and merges are being done on new site features for for the past 3 days. Yet, server crash pull request was edited to remove “emergency” from description first thing Monday and sits without any urgency attention.
This is the same pattern I saw for the past 2 months regarding server crashes related to PostgreSQL.
So, now the conclusion is that other instances do not matter, and that there was no reason for site_id field to be in the design of the table itself. That is how they are reading the code…
I spent all my time commenting out loud on GitHub on Sunday explaining why I thought the design was fine, and the UPDATE with no WHERE clause was a mistake.
Further, the going-backwards approach is to remove federation. To act like Reddit, a site that does not federate. The going-forwards with federation approach is to start having many rows updated in site_aggregates by replicating them with other instances and having information about remote persons, remote communities, remote sites (instances, site_aggregates) updated every hour, or 4 hours, or 12 hours.
Further, they seem to think that the performance issue is ONLY with deletes. In fact, the bug is there with INSERT of comment and INSERT of post. Which is hammering PostgreSQL by updating 1700 rows of site_aggregates with count = count +1 change that lacks a WHERE clause! I spelled this out Sunday! But this Wednesday comment from 2 hours ago on GitHub implies that the only performance issue is only of concern regarding DELETE. DELETE isn’t even that common of a transaction in the world, people mostly do not delete their comments and posts. The disk I/O of writing the UPDATE to 1700 rows of site_aggregate data is WAY MORE than the INSERT into the comment table of the comment itself! The concurrent users, doing their constant post creation and comment creation, are creating a locking nightmare on that TABLE in contention for constant updates while the DELETE is a rare event that smashes into those locks.
Is this more social hazing?
Long Distance Runaround, this is elaborate hazing going on against the entire social media of the World Wide Web… to ignore the server crashes systemically for 60 days and even when I personally create corrected PostgreSQL TRIGGER FUNCTION updates on Sunday evening… be well into the workday Wednesday not deploying the trivial fix/change. Let alone, seeing PostgreSQL falling over constantly and existing developers not reviewing or drawing attention to the TRIGGER code and logic (or only mention it in a casual GitHub issue). I’m a project newcomer, they have been working on it for 4 years and knew about the behind-the-scenes (hidden) PostgreSQL TRIGGER functions.
It is hazing, right? It has to be social hazing. They have known since June 4.
I still remember that dream there… https://www.youtube.com/watch?v=ZS-k02hf-hI … count to one hundred.
Long distance runaround Long time waiting to feel the sound I still remember the dream there I still remember the time you said goodbye Did we really tell lies Letting in the sunshine Did we really count to one hundred Cold summer listening Hot color melting the anger to stone I still remember the dream there I still remember the time you said goodbye Did we really tell lies Letting in the sunshine Did we really count to one hundred Long distance runaround Long time waiting to feel the sound I still remember the dream there I still remember the time you said goodbye Cold summer listening Hot colour melting the anger to stone I still remember the dream there I still remember the time you said goodbye Did we really tell lies Letting in the sunshine Did we really count to one hundred Looking for the sunshine