I wrote:
> I think a good case could be made for ripping out what's there now
> and just redefining nextVictimBuffer as a pg_atomic_uint64 that we
> never reset (ie, make its comment actually true). Then ClockSweepTick
> reduces to
> pg_atomic_fetch_add_u64(&StrategyControl->nextVictimBuffer, 1) % NBuffers
> and when we want to know how many cycles have been completed, we just
> divide the counter by NBuffers.
Actually ... we could probably use this design with a uint32 counter
as well, on machines where the 64-bit operations would be slow.
In that case, integer overflow of nextVictimBuffer would happen from
time to time, resulting in
1. The next actual victim buffer index would jump strangely. This
doesn't seem like it'd matter at all, as long as it was infrequent.
2. The computed completePasses value would go backwards. I bet
that wouldn't matter too much either, or at least we could teach
BgBufferSync to cope. (I notice the comments therein suggest that
it is already designed to cope with completePasses wrapping around,
so maybe nothing needs to be done.)
If NBuffers was large enough to be a significant fraction of UINT_MAX,
then these corner cases would happen often enough to perhaps be
problematic. But I seriously doubt that'd be possible on hardware
that wasn't capable of using the 64-bit code path.
regards, tom lane