It had SQL like syntax for manipulating data, but it was interactive. So you would SELECT the rows from the table that you wanted, then those rows would be part of your state. You would then do UPDATE or DELETE without any kind of WHERE, because the state had your filter from the previous SELECT.
It has a fun quirk though - if your SELECT matched no rows, the state would be empty. So SELECT foo WHERE 1=2 would select nothing.
UPDATE and DELETE are perfectly valid actions even without a state...
Working late one night, I ran a SELECT STKM WHERE something that matched nothing, then before I realised I realised my state had no rows matched, I followed up with DELETE STKM.
Yep, the entire Stock Movements table four the last 20+ years of business were gone.
The nightly backup had not run, and I didn't want to lose an entire day of processing to roll back to the previous night.
I spent the entire night writing a program to recreate that data based on invoices, purchase orders, stocktake data, etc. I was able to recreate every record and got home about 9am. Lots of lessons learnt that night.
> UPDATE and DELETE are perfectly valid actions even without a state
Some may call this a fun quirk :) but I'd call it a horrible mistake in the design of the system! It should have been conceptually obvious to the designer that an empty set of rows is a perfectly valid state and is fundamentally different from "no state".
It was obviously designed by someone who had not taken any courses in formal languages, compilers and algorithms.
It had a fun quirk, the final result would change depending on which names you used for your variables.
When the phd student guiding our lab session told me to not use underscores in my variable names, I thought i'd humor her just to show her it was a stupid suggestion. But she knew more than me.
Some of the early SAN disk arrays used to use an assembly like config interface with no sanity checks, type in the wrong command and you could wipe the whole array.
The company I worked for at the time had a blanket policy that any change had to be implemented by the vendor to shift liability for any mistakes.
A friend of mine worked for a company repairing transmissions on drilling platforms. To say it was a specialty shop is an understatement. However, they had been in business for 40 years. While not a computer system from the 60s, theirs was a custom written solution from the 80s running on a DOS 286 PC. It was stuck on the top shelf of a closet with a UPS. The developer had long been "permanently" unavailable for at least a decade, and they were too scared to loose the data in having it rebuilt. I asked how scared, and the answer was "it's the only computer in the building with a UPS". I'm laughing at the insanity just retelling the story
You deserve an award !!!
15 years and counting since wiping out a large production table and taking a day to restore from backup.
Never have truer words been spoken.
As I tell all the new juniors at work doing sysadmin type tasks, everyone has deleted the production database at least once. Mistakes will always happen, it's how you deal with them that defines how good you are at the end of the day.
Management reacted pretty well. They assured both of us that while we made the mistake, it was not our fault that data was lost: the problem was that backups were not being checked, which caused us to lose the resulting three days (120 developer days) of work. The manager in charge of the folks doing the backup got taken to task - but nobody else did.
For whatever reason, we had write access to that directory, but not deletion. I had to get the teacher to delete it for me.
This is very much dependent on the circumstances - sometimes people won't be supportive or encouraging, but cold at best and toxic (rude, making fun of mistakes, letting their egos run wild) at worst. This is more likely to happen in some work cultures/companies than others, and there can also be individuals that are allowed to persist with their problematic conduct in otherwise okay environments.
If you are ever in such environments, acknowledge the fact, possibly push back against stuff like that and definitely be on the lookout for alternatives, where you'd be able to prosper.
Thankfully, my personal experiences have mostly been okay, but I've definitely seen both attitudes and choices that can make everyone's lives worse, to the point where I wrote the satirical article "The Unethical Developer's Guide to Personal Success": https://blog.kronis.dev/articles/the-unethical-developers-gu...
Don’t ask me how I learned this.
1. Start a transaction before even thinking of writing the delete/update/etc (BEGIN; ...)
2. Always write the WHERE query out first, THEN go back to the start of the line and fill out the DELETE/UPDATE/etc.
It worked well, and it's a habit I've since tried to keep on doing myself as well.
Now I have learnt to instinctively stop before doing anything destructive and double-check and double-check again! This also applies to SQL `DELETE` and `UPDATE`!
I know that `-r` was not neccessary but hey that was a biiiig mistake of mine!
find /backups/ -mtime '-30' -printf 'rm -f %p\n' > very_scary_deletes.sh
One of my "oopsies" involved aggressive <up> and <enter> usage and a previous `rm -rf *` running in /home...
Joke's on you, we all learned it this exact way.
thankfully my boss at the time was a amazing db admin and he helped me fixing my mistake.
Turns out when you start loading millions of rows of useless data into memory, the useful data has to get kicked out, and that makes query latency skyrocket.
Lesson learned: even if you are under big pressure take your time to plan and review the modification 15 minutes can save hours.
It turned out, for some arcane reason I still don't understand, our production instance of Artifactory was running on top of Docker Compose with host path volume mounts, and somehow, symlinks that were not valid from the perspective of the host actually were valid from inside the container, and doing this on all of our servers broke Artifactory. For some even stupider reason, we weren't doing full filesystem-level snapshots at any regular interval (which we started doing after this), so instead I needed to enlist the help of the classic wizard ninja guy who had been acting as a mostly unsupervised one-man team for the past six years who had hacked all of this mess together, documented none of it, and was the only person on the planet who knew how to reconstruct everything.
This was probably still only the second-stupidest full on-prem lab outage I remember, behind the time the whole network stopped working and the only person who had been around long enough remembered they had trialed a temporary demo hardware firewall years earlier, management abandoned the evaluation effort, and it somehow remained there as the production firewall for years without ever being updated before finally breaking.
"You're not a real technology worker until you've brought the company down. Welcome."
Might not be the best words to live by, but it was exactly what I needed to hear at that time early in my career.
"One of us!! One of us!!" :-)
>_< , something similar happened to me when I did an rm -Rf * in the old pictures directory on my system ... Well ... It wasn't the old pictures directory, it was the backup directory with all pictures from my older phone !! To say that blood drained from my face would be an understatement, thankfully I was able to recover most of it.
The first thing I did after the recovery marathon was to alias rm so that it instead works by moving stuff to /tmp
fdisk
Then come the “site is down and the world is ending” tickets, messages, emails, and phone calls.
You can set colours for local/test/prod servers and a red colored tab will scream at you to be cautious. And with red color every edit will pop up an "are you sure?" question. And autocommit is off.
I sorta stopped making unrecoverable mistakes.
Hop in the test database, run some SQL, update a bazillion records, run some selects to verify, open the test app and verify there. All good! Someone else checks… LGTM.
So I do the same thing in prod. Make changes, validate in the DB, looks good. Open the prod app… down. Requests are hanging.
Our software is shit so I’m not surprised. I start frantically digging through trying to figure out where and why it’s hanging. Eventually chase it down to some lock wait timeouts in SQL. Start looking at the database… no queries seem to be running against the table in question. Eventually dig a little deeper and find… the call was coming from inside the house! The locks are held by my connection. Go hit “commit” in dbeaver and prod comes right back up.
And that’s the boring story of the day I learned that dbeaver used transactions in prod connections by default.
I just checked it out, and it looks promising.
Con: There are too many licensing options. I'm not even sure which one I would need.
Pro: They'll send out an invoice, like a real company. I work for a billion-dollar healthcare company, and if your company only takes PayPal, or Venmo, or something else that makes it look like two guys in a basement, it'll never get through our purchase approval process. Big companies do business with other big companies. Startups have to learn to interface with businesses on a business level if they ever want to grow out of being a startup.
All of the tutorials I seem to find online are basic level and/or mixed with introducing SQL.
click ok on the update dialog, wait until the download finishes, shut down the app, drag the new app over to Applications, click Replace, wait for the actual moving dialog to pop up, wait for the moving dialog to finish, minimize all your windows so you can see the desktop, unmount the dbeaver image, click dbeaver again
and you can get back to work! now if only I could remember all the details that were in my head when i opened the app in the first place...
dbeaver team: can you do what paint.net did please? that is, only bother me to update as i'm turning the app off, not on?
I run a local copy of the database I connect to remotely and I have to be careful about which database/table I’m connected too.
I decided on bacula - I had the clients installed on all the computers in the office, and it worked for some small tests.
My manager decided we would try this with a USB drive attached to one of the servers (somehow this didn't seem like a bad idea).
In the morning, very uncaffinated he sent me to the other site - an unmanned basement office with the servers.
Being uncaffinated I forgot the door password and set off the alarm.
I had to go into the office and phone him with the alarm going to get the code to turn the alarm off.
OK, that was stressful but sorted out at least.
I plugged in the hard drive to the selected server and headed back.
Once I got back it turned out all the websites on that server had gone down - trying to send all the backups to this poor USB harddrive had overwhelmed the IO on that-era Linux server and the poor thing just froze.
Fairly soon after I was let go, and joined my friends at a much more fun company making mobile games.
I was once let go from a big name university for refusing to weaken and rush changes to a payment processing network (PCI-DSS) when there was "no time" to review them in detail. That's a future FBI press conference sort of thing when it all comes crashing down. Not long after, all SS#s, DOBs, and deets for every employee was stolen from a "rogue" laptop taken by a consultant, likely to be sold on carder and identity theft forums because of an utter failure at data protection processes. That place was a shitshow because they didn't have the professional ethics or leadership backbone to do what was prudent and necessary.
Not only an USB (1?) could cause it but also a cifs transfer over a 100 Mbps link.
The old grey haired sysadmin backs up the directory so he can instantly restore it. Seems this happens all the time.
Whew.
If the author had decided to say nothing the problem would have been bigger - an unhappy boss and probably fired.
We had a redis with sessions. Early on, someone decided every write to redis should also cause a write to S3 as backup. My first task was to get rid of this 4-digits a month extra cost in PUT requests. I decided to instead write all changed session objects into a set keyed by half-hour timestamps and then write only those sessions every 30 minutes. Unfortunately initially I used a KEYS to find the set corresponding to my half-hour stamp, not having read up exactly on what it does. It's not exactly advisable to do on a redis with a million or so objects. A later version of the archiver wrote the last emptied set to a stable key instead and then checked the set keys between then and now instead...
1. Write your WHERE clause first 2. Return to the beginning of the line to finish writing the statement 3. Check your statement 4. If it looks good, then -- and only then -- add your closing semicolon
Having said that, once during my second week at a new company, I plugged in an ethernet cable to an APC UPS, so I could set up networking on it. It shut down production. Why? APC makes (for that model at least) proprietary ethernet cables for networking, and if you plug in a regular cable it does an autoshutdown...an engineers attempt at marketing perhaps!? I did RTFM before, and after out of confusion, and there was no mention of this.
SELECT * from table
WHERE id = 12345
SELECT * from table
-- UPDATE table set c1 = v1, c2 = v2
WHERE id = 12345
(Most of the RDBMS tools that I've used would happily ignore the lack of a closing semi-colon and that will not save you for a single-statement case.)
Aka DELETE ALL where x == y or DELETE MANY where x == y or perhaps you need an explicit limit for it to not be 1, so DELETE where x == y LIMIT ALL
> Sorry! Subscriptions were broken last week, but are now working. If you tried to subscribe and ran into issues, please try again!
I wonder if a similar incident involving a “UPDATE subscriptions” query happened recently.
It also apparently requires double email configuration, meaning it has two places where you can configure your mailer. I had only set it up in one place, meaning the confirmations never got sent.
Bit of a facepalm moment.
When the service started, they made the decision to not actually delete any content (delete just set a flag which disabled the content but didn't actually remove it).
Fast forward a year or so, and it became clear that a real delete was needed. So they had a junior engineer write up a sort of delayed sweep - delete all the videos with the delete flag set. But then, for some reason, they decided put the implementation behind a delay. Something like "actually delete all soft-deleted videos, but don't start doing it until 30 days from now". However, unbeknownst to the team, there was a bug in the implementation that deleted everything, regardless of whether the 'delete' flag was set.
So one night, roughly a month later, all the content started disappearing from the site. One guy heroically tried to stop the process, but I think he was too late. The engineering director happened to be on a vacation down in South America somewhere and I think the founder fired him in a fit of pique. I managed to reclaim a small bit of content (basically the videos that were cached on the actual recording servers before they were uploaded to S3).
You can imagine the technical over-reaction:
* Delete switched back to a soft delete
* Turned on S3 object versioning
* Started redundantly copying content onto a totally different hosting service
As you might expect, we lost a ton of users over mass content deletion and the service never really rebounded. The company held on for a couple more years, pivoting a couple of times, but eventually folded.
Hopefully you work with people that follow that as well.
I can still remember a more senior coworker copying a directory from a network share (Ctrl + C), deleting the directory, and then trying to paste it somewhere else.
I didn't speak up (he also rarely touched the mouse so flew through it), so we both got a chuckle when he realized his mistake and pinged network folks for a backup from tape.
It happens. The real world is messy. Can always learn something new. Can always do something you know not to do.
/s
rmdir . /s /q
And repeat the same error years later when the batch file failed to cd to the destination folder. Added
if %CD% == %DESTDIR%
Did much the same, but only on my own system (thankfully!) and yes, I had an up-to-date backup MySQL dump on hand.
I think this goes against every principle most on HN have.
Whatever had gotten into it, it rolled back to 2009. It rolled everything back, including user accounts.
No-one who worked there in 2009 still worked there, so no-one had a valid password any more.
Fortunately it was easy enough to copy the last-but-one backup over the top and lose the day before's config updates, and cure its Flowers for Algernon state, but it was a pretty hairy afternoon.
"But now all has been deleted??!?! WTF HEEELP"
"I apologize for my previous answer, you are correct, you now deleted everything!"