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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2006-12-05 22:05:20 | Re: psql possible TODO |
Previous Message | Alvaro Herrera | 2006-12-05 21:55:04 | Re: psql possible TODO |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-05 22:26:13 | Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3) |
Previous Message | Tom Lane | 2006-12-05 21:24:52 | Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3) |