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: | 1165348403.3839.212.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
xlogswitchtuning.patch | text/x-patch | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2006-12-05 19:53:55 | trappable warnings, dynamic change of minimal level for PG_RE_THROW |
Previous Message | Andrew Dunstan | 2006-12-05 18:52:46 | Re: Weak passwords and brute force attacks |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-05 20:14:39 | Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3) |
Previous Message | Neil Conway | 2006-12-05 17:36:27 | Re: typo in contrib/hstore/hstore_io.c |