On Thu, 2006-03-23 at 11:27 -0800, Mark Wong wrote:
> On Wed, 22 Mar 2006 14:19:48 -0500
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > Mark Wong <markw@osdl.org> writes:
> > > I proposed to explore splitting BLCKSZ into separate values for logging
> > > and data to see if there might be anything to gain:
> > > http://archives.postgresql.org/pgsql-hackers/2006-03/msg00745.php
> > > My first pass was to do more or less a search and replace (attached) and
> > > I am already running into trouble with a 'make check' (below). I'm
> > > guessing that when initdb is run, I'm not properly saving the values
> > > that I've defined for DATA_BLCKSZ and possibly LOG_BLCKSZ.
> >
> > I'd suggest leaving BLCKSZ as-is and inventing XLOG_BLCKSZ to be used
> > only within the WAL code; should make for a *far* smaller patch.
> > Offhand I don't think that anything except xlog.c knows the WAL block
> > size --- it should be fairly closely associated with dependencies on
> > XLOG_SEG_SIZE, if you are looking for something to grep for.
>
> Ok, I have attached something much smaller. Appears to pass a 'make
> check' but I'll keep going to make sure it's really correct and works.
AFAICS this patch won't work properly yet, even though the idea is cool.
Backup data blocks have the "hole" removed from them in xlog.c. This is
definitely BLCKSZ not XLOG_BLCKSZ at lines 675,798,799 and 813 maybe
others. But then you need to put them into a block of size XLOG_BLCKSZ,
e.g. line 708. It might be worth looking at xlog.c for 8.0 to see which
places used BLCKSZ before hole-removal was introduced in 8.1.
I think we should set the default wal_buffers setting to 16 at least
now, if we are halving the default size of the blocks. 32 might be more
realistic for 8.2.
Best Regards, Simon Riggs
