Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3)

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