On Tue, 2006-12-05 at 16:24 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
