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

Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3)

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>,<pgsql-hackers(at)postgresql(dot)org>,<pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3)
Date: 2006-12-05 19:53:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Mon, 2006-11-27 at 18:26 -0500, Tom Lane wrote:
> [ studies code a bit more... ]  I'm also wondering whether the forced
> pg_control update at each xlog seg switch is worth its keep.  Offhand
> it
> seems like the checkpoint pointer is enough; why are we maintaining
> logId/logSeg in pg_control?

We maintain the values in shared memory to allow us to determine whether
or not its time to checkpoint, and also to ensure that there is one and
only one call to checkpoint. So we need to keep track of this somewhere
and that may as well be where it already is.

However, that doesn't mean we need to update the file on disk each time
we switch xlog files, so I've removed the UpdateControlFile() at that
point. That fsync was done while holding WALWriteLock() so removing it
should be good for a few extra points of speed - at least we know there
were some problems in that area.

  Simon Riggs             

Attachment: xlogswitchtuning.patch
Description: text/x-patch (1.4 KB)

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2006-12-05 19:53:55
Subject: trappable warnings, dynamic change of minimal level for PG_RE_THROW
Previous:From: Andrew DunstanDate: 2006-12-05 18:52:46
Subject: Re: Weak passwords and brute force attacks

pgsql-patches by date

Next:From: Tom LaneDate: 2006-12-05 20:14:39
Subject: Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3)
Previous:From: Neil ConwayDate: 2006-12-05 17:36:27
Subject: Re: typo in contrib/hstore/hstore_io.c

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