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

Remove log segment and log_id fields from pg_controldata

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Remove log segment and log_id fields from pg_controldata
Date: 2007-02-04 01:37:33
Message-ID: 200702040137.l141bX018660@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
The original discussion of this patch was here:

	http://archives.postgresql.org/pgsql-hackers/2006-11/msg00876.php

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Simon Riggs wrote:
> On Tue, 2006-12-05 at 17:26 -0500, Tom Lane wrote:
> > "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > > On Tue, 2006-12-05 at 16:24 -0500, Tom Lane wrote:
> > >> Sure, what would happen is that every backend passing through this code
> > >> would execute the several lines of computation needed to decide whether
> > >> to call RequestCheckpoint.
> > 
> > > Right, but the calculation uses RedoRecPtr, which may not be completely
> > > up to date. So presumably you want to re-read the shared memory value
> > > again to make sure we are exactly accurate and allow only one person to
> > > call checkpoint? Either way we have to take a lock. Insert lock causes
> > > deadlock, so we would need to use infolock. 
> > 
> > Not at all.  It's highly unlikely that RedoRecPtr would be so out of
> > date as to result in a false request for a checkpoint, and if it does,
> > so what?  Worst case is we perform an extra checkpoint.
> 
> On its own, I wouldn't normally agree...
> 
> > Also, given the current structure of the routine, this is probably not
> > the best place for that code at all --- it'd make more sense for it to
> > be in the just-finished-a-segment code stretch, which would ensure that
> > it's only done by one backend once per segment.
> 
> But thats a much better plan since it requires no locking.
> 
> There's a lot more changes there for such a simple fix though and lots
> more potential bugs, but I've coded it as you suggest and removed the
> fields from pg_control.
> 
> Patch passes make check, applies cleanly on HEAD.
> pg_resetxlog and pgcontroldata tested.
> 
> 
> -- 
>   Simon Riggs             
>   EnterpriseDB   http://www.enterprisedb.com
> 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-02-04 01:51:08
Subject: Re: psql possible TODO
Previous:From: Jan WieckDate: 2007-02-04 01:02:26
Subject: Re: Proposal: Change of pg_trigger.tg_enabled and adding

pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-02-04 02:38:07
Subject: Re: Bundle of patches
Previous:From: Bruce MomjianDate: 2007-02-04 00:04:03
Subject: Re: Index split WAL reduction

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