Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3)
Date
Msg-id 1165352481.3839.230.camel@silverbirch.site
Whole thread Raw
In response to Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3)
List pgsql-hackers
On Tue, 2006-12-05 at 15:14 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > 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.
>
> Say again?  AFAICT those fields are write-only; the only place we
> consult them is to decide whether they need to be updated.  My thought
> was to remove 'em altogether.

Thats what I thought originally.

However, they guard the entrance to RequestCheckpoint() and after they
have been set nobody else will call it - look at the test immediately
prior to the rows changed by the patch. That comparison is why we still
need them and why they aren't just write-only.

So they need to be there, but we just don't need to write them to
pg_control.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql possible TODO
Next
From: "Joshua D. Drake"
Date:
Subject: Re: psql possible TODO