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 1165355897.3839.245.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)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2006-12-05 at 16:24 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: psql possible TODO
Next
From: "Joshua D. Drake"
Date:
Subject: Re: psql possible TODO