Re: [HACKERS] Further plans to refactor xlog.c
On Fri, Nov 4, 2011 at 2:16 PM, Fujii Masao masao.fu...@gmail.com wrote: On Fri, Nov 4, 2011 at 3:14 AM, Simon Riggs si...@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? Oh, you've already posted the patch which does that. http://archives.postgresql.org/message-id/CA+U5nMK=ybzczkdvj8kojfsz+d9lfmxvw+928nhu4x1hbyh...@mail.gmail.com Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Further plans to refactor xlog.c
On Fri, Nov 4, 2011 at 5:26 AM, Fujii Masao masao.fu...@gmail.com wrote: Additionally what about moving all built-in functions defined in xlog.c to xlogfuncs.c? Oh, you've already posted the patch which does that. http://archives.postgresql.org/message-id/CA+U5nMK=ybzczkdvj8kojfsz+d9lfmxvw+928nhu4x1hbyh...@mail.gmail.com Committed -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Further plans to refactor xlog.c
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? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Further plans to refactor xlog.c
On Fri, Nov 4, 2011 at 3:14 AM, Simon Riggs si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
