Skip site navigation (1) Skip section navigation (2)

Re: Large C files

From: Greg Stark <stark(at)mit(dot)edu>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jan Urbański <wulczer(at)wulczer(dot)org>
Subject: Re: Large C files
Date: 2011-09-09 22:54:18
Message-ID: CAM-w4HOjJQu9J8skM3CODRCoyJo2pwukGisxsjRTvSfAF4bPMA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Sep 9, 2011 at 6:57 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> In particular, I'd like to know what
>> boundaries it is envisaged that the code should be refactored along to
>> increase its conceptual integrity, or to better separate concerns. I
>> assume that that's the idea, since each new .c file would have to have
>> a discrete purpose.
>
> I'd like to see it split into routines involved in writing WAL, and those
> involved in recovery. And maybe a third file for archiving-related stuff.

Having a clean API for working with WAL independently of recovery
would let us have a maintainable xlogdump tool that doesn't constantly
get out of sync with the wal archive format. It would also make it
easier to write things like prefretching logic that requires reading
the upcoming xlog before its time to actually replay it.


-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-09-09 23:06:49
Subject: Re: Patch to improve reliability of postgresql on linux nfs
Previous:From: Greg StarkDate: 2011-09-09 22:48:17
Subject: Re: Protecting against multiple instances per cluster

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group