Hi hackers StartupXLOG is 1549 lines of code. Its unwieldy size came up in a discussion in an IRC channel where some PG hackers lurk and I decided to see how it might be chopped up into subroutines with a clear purpose and reasonable size, as an exercise.
I came up with the following on a first pass, though obviously you
could go a lot further:
StartupXLOG -- reduced to 651 lines
-> ReportControlFileState() -- 40 lines to log recovery startup message
-> ReportRecoveryTarget() -- 32 lines to log recovery target message
-> ProcessBackupLabel() -- 90 lines to read backup label's checkpoint
-> CleanUpTablespaceMap() -- 33 lines of file cleanup
-> BeginRedo() -- 191 lines for redo setup
-> BeginHotStandby() -- 74 lines for hot standby initialisation
-> ReplayRedo() -- 260 lines for the main redo loop
-> FinishRedo() -- 63 lines for redo completion
-> AssignNewTimeLine() -- 66 lines
-> CleanUpOldTimelineSegments() -- 74 lines of file cleanup
-> RecoveryCheckpoint() -- 71 lines
Unfortunately the attached sketch patch (not tested much) is totally
unreadable as a result of moving so many things around. It would
probably need to be done in a series of small well tested readable
patches moving one thing out at a time. Perhaps with an extra
context/state object to cut down on wide argument lists.
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.
--
Thomas Munro
http://www.enterprisedb.com
refactor-startupxlog-sketch.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
