Regular Restarts Are Good, Actually
Anecdotally, one of the more maligned features of the Heroku platform are the 24-hour limits on compute units, known as “dynos”. This is actually a good thing, but very misunderstood.
Anecdotally, one of the more maligned features of the Heroku platform are the 24-hour limits on compute units, known as “dynos”. This is actually a good thing, but very misunderstood.
A quick explanation of the Okta AD/LDAP DelAuth bug that was being shared around, and the importance of sensible defaults.
There are two programming principles that I hold dear to my heart: the principle of least surprise and provide sensible defaults. I’ve recently been working within the GraphQL ecosystem, and the number of violations of both here has frustrated me. This will be a little bit ranty.
I’ve been managing a fully remote, fully distributed team, covering timezones from UTC-8 through UTC+10, for the last couple of years. Through that time, I’ve learned a lot on organising work, interpersonal relationships, and ultimately how to overcome a lack of promximity to my reports.
At $WORK
, we have a case where we have implemented an event trigger to prevent customers from dropping an extension. As this extension is part of contrib
and normally installed by users, we can’t prevent them from dropping it normally. However, event triggers can only be created by superusers, so a pg_dump
of the database creates a dump that can’t be restored by a non-superuser. To solve this, lets implement a custom pg_dump
that optionally excludes event triggers.
You can see the following implementation in this diff on my fork of the Postgres repository.