Re: Further plans to refactor xlog.c - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Further plans to refactor xlog.c
Date
Msg-id CAHGQGwGN4W-0Mw=JPuzXn2VpLkymNL0fsM+3BwzzqqkVvkQB5w@mail.gmail.com
Whole thread Raw
In response to Further plans to refactor xlog.c  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Further plans to refactor xlog.c
List pgsql-hackers
On Fri, Nov 4, 2011 at 3:14 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Next steps in refactoring are bigger steps, but not huge ones.
>
> I propose this
>
> * everything to do with XLOG rmgr into a file called xlogrmgr.c
> Thats xlog_redo() and most everything to do with checkpoints
>
> * everything to do with reading WAL files into a file called xlogread.c
> That will allow us to put pg_xlogdump into core
>
> * possibly some more stuff into xlogboot.c
>
> The above actions will reduce xlog.c to about 7000 lines, about 4000
> lines smaller than when I started. That sounds like it could go
> further, but it moves out most of the areas of recent growth by
> focusing on the purpose of that code.
>
> An obvious split would seem to be move all recovery-side code into its
> own file. That seems quite likely to take a lot of time, break
> something, as well as requiring us to share XLogCtl, all of which
> personally I would rather avoid.
>
> Fujii's work is likely to remove another few hundred lines as well.
>
> That seems enough to me.... OK?

Additionally what about moving all built-in functions defined in xlog.c
to xlogfuncs.c?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Online base backup from the hot-standby
Next
From: Magnus Hagander
Date:
Subject: Re: IDLE in transaction introspection