Lately, I’m finding that Postgres is becoming more and more vital to my development workflow. My days of leaning on an ORM like Rails' ActiveRecord in order to get away with treating the database as a dumb hash are long behind me.
As a result, even though I’ve optimized my development setup for quickly wiping and reinitializing my entire Mac, lately I’ve found myself needing to frequently clear out any trace of my Postgres installation. In particular, and while I absolutely adore my M1 Mac, a few people have noticed that—for whatever reason—Postgres can experience some data corruption issues when run under Rosetta. Specifically, I’ve been seeing a lot of errors that look like this lately:
PG::InternalError: ERROR:
could not read block 138 in file "base/645837/646529":
Bad address:
Even though the errors are erratic and typically disappear when I try the query again, that doesn’t do much to inspire confidence that whatever I’m working on isn’t going to blow up in production. The “right” thing to do would be to dig in and figure out what’s causing this. Maybe Rosetta isn’t enabled in every context? Maybe there’s a bug in architecture-specific code inside Postgres? Maybe the otherwise flawless Rosetta team missed a spot?
Unfortunately, I don’t have the time or expertise to perform a root cause analysis of why my local Postgres installation is borked—I just want to make the hurting stop. So, I stuck to what I know: firing off a drive-by tweet and then nuking my installation and starting over.
Completely uninstalling a Homebrew installation of Postgres
Okay, so now that you’ve read my life story, we can get to the recipe.
Here are a few quick steps to uninstall Postgres, verify you deleted everything, and then reinstall it.
It should go without saying, but beware: running these commands will delete all your local Postgres databases. With that warning out of the way, here are the lines to blindly copy and paste into your terminal:
$ brew uninstall postgres
$ rm -rf /usr/local/var/postgres
$ rm /usr/local/var/log/postgres.log
$ rm -f ~/.psqlrc ~/.psql_history
It might seem like brew uninstall postgres
should be sufficient, but it alone won’t actually delete any of your data (which will be left behind in /usr/local
).
But did that remove everything?
Want to make sure you didn’t miss anything? Feel free to kick the tires a bit more.
If you want to make sure there are no other Postgres-adjacent Homebrew formulae still installed:
$ sudo find / -name "*postgres*" -o -name "*psql*"
[Note: By the way, are you ever annoyed when you accidentally paste a leading $
character from a code snippet into your terminal? Consider adding an executable on your PATH like this one that will effectively turn $
into a no-op that’s safe to paste.]
You can also search your entire system for file name matches:
$ sudo find / -name "*postgres*" -o -name "*psql*"
Because the above command scans your entire disk, don’t be surprised if the it triggers permission pop-ups for Terminal.app app to access your Desktop, Documents, Contacts, Photos, etc.
Re-installing Postgres
If you’re as paranoid as I am, you’ve probably already restarted your computer several times while reading this post. But in case you haven’t yet, it might be a good time to reboot your machine. Come back here once you’re ready to experience that fresh database feeling.
First, to make sure you’re getting the latest and greatest of everything, make sure Homebrew is fully updated:
$ brew update
Then give Homebrew a chance to diagnose any problems:
$ brew doctor
If you’re not familiar with brew doctor
, the name of the game is to keep doing what it tells you and re-running it until it exits cleanly with the simple message:
$ brew doctor
> Your system is ready to brew.
Now, to actually install Postgres and ensure that it’s running:
$ brew install postgres
$ brew services start postgresql
Several Postgres commands and apps will assume that there exists a database of the same name as your user account, so it’s best to create one straight away:
$ createdb `whoami`
If all those commands succeeded, you should be ready to roll with a clean, not-yet-corrupted Postgres installation. I look forward to seeing you again the next time it manages to get gunked up!