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 21:58:16
Message-ID: 1165355897.3839.245.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Tue, 2006-12-05 at 16:24 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > On Tue, 2006-12-05 at 15:14 -0500, Tom Lane wrote:
> >> 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.
> 
> 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.  That's still way cheaper than an xlog switch
> as a whole, so it doesn't bother me.  I think the first test is probably
> effectively redundant anyway, since the whole thing is executed with
> WALWriteLock held and so there can be only one backend doing it at a
> time --- it's not apparent to me that it's possible for someone else to
> have updated pg_control before the backend executing XLogWrite does.

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. 

Yes, one backend at a time executes this code, but we need a way to tell
whether the backend is the first to come through that code.

I just left it with the lock it was already requesting. If you really
think it should use infolock then I'll code it that way instead.

> But in any case, the point here is that it doesn't matter whether the
> RequestCheckpoint code is inside the update-pg_control test or not.
> It was only put there on the thought that we could save some small
> number of cycles by not doing it if the update-pg_control test failed.

Understood, that wasn't why I left it that way.

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



In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2006-12-05 22:05:20
Subject: Re: psql possible TODO
Previous:From: Alvaro HerreraDate: 2006-12-05 21:55:04
Subject: Re: psql possible TODO

pgsql-patches by date

Next:From: Tom LaneDate: 2006-12-05 22:26:13
Subject: Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3)
Previous:From: Tom LaneDate: 2006-12-05 21:24:52
Subject: Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3)

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