I accidentally removed the WHERE clause from my SQL query in a personal tool. Every row is now the same. I overwrote 206,000+ rows. I have no backup, I am stupid.
I accidentally removed the WHERE clause from my SQL query in a personal tool. Every row is now the same. I overwrote 206,000+ rows. I have no backup, I am stupid.
"UPDATE table_name SET w = $1, x = $2, z = $4 WHERE y = $3 RETURNING *",
does not do the same as
"UPDATE table_name SET w = $1, x = $2, y = $3, z = $4 RETURNING *",
It's 2 am and my mind blanked out the WHERE, and just wanted the numbers neatly in order of 1234.
idiot.
FML.
You're viewing a single thread.
This is a hard lesson to learn. From now on, my guess is you will have dozens of backups.
And a development environment. And not touch production without running the exact code at least once and being well slept.
Fuck that, get shit housed and still do it right. That's a pro.
That's not pro, that's just reckless gambling.
Totally right! You must set yourself up so a fool can run in prod and produce the expected result. Which is the purpose of a test env.
Replied hastily, but the way to run db statements in prod while dealing with sleep deprivation and drinking too much is to run it a bunch in several test env scenarios so you're just copy pasting to prod and it CAN confidently be done. Also enable transactions and determine several, valid smoke tests.
Edit: a -> several
And always use a transaction so you're required to commit to make it permanent. See an unexpected result? Rollback.
Transactions aren't backups. You can just as easily commit before fully realizing it. Backups, backups, backups.
Yes, but
- Begin transaction
- Update table set x='oopsie'
- Sees 42096 rows affected
- Rollback
Can prevent a restore, whereas doing the update with auto commit guarantees a restore on (mostly) every error you make
Can prevent a restore, whereas doing the update with auto commit guarantees a restore on (mostly) every error you make
Exactly. Restores often result in system downtime and may take hours and involve lots of people. The backup might not have the latest data either, and restoring to a single table you screwed up may not be feasible or come with risk of inconsistent data being loaded. Even if you just created the backup before your statement, what about the transaction coming in while you're working and after you realize your error? Can you restore without impacting those?
You want to avoid all of that if possible. If you're mucking with data that you'll have to restore if you mess up, production or not, you should be working with an open transaction. As you said... if you see an unexpected number of rows updated, easy to rollback. And you can run queries after you've modified the data to confirm your table contains data as you expect now. Something surprising... rollback and re-think what you're doing. Better to never touch a backup and not shoot yourself in the foot and your data in the face all due to a stupid, easily preventable mistake.
Backups are for emergencies.
Transactions are for oopsies.
I've read something like "there are two kinds of people: those who backup and those who are about to"
This is the way