On 7 September 2016 at 10:54, Noah Misch <noah@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
