On 7 September 2016 at 10:54, Noah Misch <n...@leadboat.com> wrote: > On Tue, Sep 06, 2016 at 01:32:10PM -0400, Christian Convey wrote: >> It sounds like the most useful thing I can do at the moment is perform >> code reviews. I assumed I'd need more experience with the PG code >> base, but I keep on reading that newcomers' reviews are welcome. >> Unless someone has a better idea, I'll start with that. > > That is a good choice. Thanks for getting involved in this way.
Yeah, code review is hard when you don't know the codebase, but it's also a good way to learn it. A reviewer who doesn't already know the part of the code of interest well is in a good position to say "hey, this makes no sense unless you know that X, Y, Z and 42, maybe you should have a comment here so the next reader doesn't have to spend 4 hours studying calls through three different subsystems to figure it out?" . That's actually quite nice for maintainability, though obviously we can't describe everything in detail everywhere, there has to be a balance. Sometimes you'll also ask "dumb" questions that force someone to explain assumptions they'd made... and in the process figure out that actually their assumptions don't fit reality / make sense. I certainly find myself writing "well, it does X" explanations then figure I should re-check, go read the code and find out that actually ... no, not so much. The main thing that's hard is knowing where to look to start learning about the basic subsystems you need to know and the ones a particular patch touches on. fmgr, relcache/syscache (and invalidation, oh fun), how the whole Datum variant business works, memory contexts, PGPROC, walsenders and walreceivers, startup process, bgwriter, checkpointer, bgworkers, latches and LWLocks, shmem and private memory and copy-on-write postmaster memory, elog/ereport(...) and longjmp() error unwinding, visibility/xmin/xmax/cmin/cmax, infomask/hintbits/locks, SLRUs and clog, multixacts and comboxacts, low level heap/index access routines, the SPI, the parser/rewriter/planner and its subsystems like inheritance_planner, extensions, timelines, logical decoding, slots, .... etc etc. We really could use a developer's primer. The current developer docs and scattered READMEs are nice for what they cover, but somewhat spotty. That said, who's volunteering? Nope nope nope! Though I am trying to blog about various subsystems occasionally. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers