Re: Refactor StartupXLOG?

On Sat, Sep 24, 2016 at 11:01 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> What would the appetite be for that kind of refactoring work,
> considering the increased burden on committers who have to backpatch
> bug fixes? Is it a project goal to reduce the size of large
> complicated functions like StartupXLOG and heap_update? It seems like
> a good way for new players to learn how they work.

A lot of appetite. The size of xlog.c is out of control, so something
that would be really cool to see is spliiting the whole logic of
xlog.c into more independent files, for example low-level file only
operations could go into xlogfile.c, backup code paths in
xlogbackup.c, etc. This would make necessary to expose some of the
shared-memory structures now at the top of xlog.c like XLogCtl but I
think that would be really worth it at the end, and closer to the
things like xloginsert.c and xlogarchive.c that began such a move.
--
Michael