5 ms·
I’m willing to accept less-than-perfect simulation of our production environment in order to speed up development, especially for settings that eg only matter i
by MaxGabriel 7y ago
I’m willing to accept less-than-perfect simulation of our production environment in order to speed up development, especially for settings that eg only matter in the case where the machine crashes (big deal in production—not in tests).
We already make a leap of faith by developing on Mac/Linux distros other than what we use in production. Making Postgres not-crash safe locally is a pretty small change compared to that.
- anarazel 7y agoOne caveat: Disabling fsyncs can hide problematic access patterns. If you were to e.g. accidentally perform a large set of DML in one-row increments and forgot to do so in one transaction, you'd not see a huge penalty in your test environment, but a lot more in production (one fsync for each transaction in the non-concurrent case). Btw, disabling synchronous_commit isn't going to do much once you've disabled fsyncs. What s_c=off basically does is to defer the journal flush to a background process that will do them regularly (unless already done by another session / reason) - but if fsync=off, that's not necessary anyway. And s_c=off does have some small overhead too.
- CameronNemo 7y agoYou can have two pipelines, one for typical development / merge requests and another for pre-releases.
- AlphaSite 7y agoI think this dev machine vs CI?