Hi,
On 2018-05-18 11:50:47 +0800, Craig Ringer wrote:
> Also - mailing lists. We're an ageing community and a lot of younger people
> just don't like or use mailing lists, let alone like to work *only* on
> mailing lists without forums, issue trackers, etc etc.
Can't see getting rid of those entirely. None of the github style
platforms copes with reasonable complex discussions.
> We also have what seems like half an OS worth of tooling to support our
> shared-nothing-by-default multi-processing model. Custom spinlocks, our
> LWLocks, our latches, signal based IPC + ProcSignal signal multiplexing,
> extension shmem reservation and allocation, DSM, DSA, longjmp based
> exception handling and unwinding ... the learning curve for PostgreSQL
> programming is a whole lot more than just C even before you get into the
> DB-related bits. And there's not a great deal of help with the learning
> curve.
A good chunk of that we'd probably have anyway. Even with threads we'd
likely have our own spinlocks, lwlocks, latches, signal handling,
explict shared memory (for hugepages). I think having a decently
performant DB will always imply a lot of "OS like" infrastructure.
I agree very much on exception handling weirdness - proper language
level exceptions are way much easier to handle, and could offer ease of
use (no volatiles!) and a lot more flexibility (say throwing errors
which signal that no DB level activity happened).
I actually don't think the earlier category is as painful as our
idiosyncracies around C's weaknesses. Lists, Node based types, dynahash
etc. are hard to avoid and failure prone.
Greetings,
Andres Freund
