"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.
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.
regards, tom lane
