Simon Riggs <si...@2ndquadrant.com> writes:
> On Sun, Jul 17, 2011 at 10:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yeah, I agree with putting the actual SetLatch call after we release the
>> lock ... but doesn't the calculation need to be done while we're still
>> holding it? Otherwise it'd be using potentially-inconsistent values.
> The calculation is just a heurustic, so doesn't need to be exactly
> accurate. We need the latest values derived while holding the lock,
> but we don't need to ensure they change while we make the calc.
> The calc needs to say "if we are the ones who make the array more than
> half full, then wake up the WALWriter". It might already be awake, it
> might be already be more than half full or it might even be less than
> half full now - none of those cases are very important.
Nonetheless, I think it'll be better to make the calculation and set a
local bool variable (to tell whether to do SetLatch later) while we're
in the midst of the advance-to-next-WAL-buffer code. Even if it's true
that we would generally get an OK answer by reading the variables again
after releasing the lock, that's highly unlikely to be a performance
win, because of cache line contention effects (ie, having to wrest the
line back from the next guy doing WALInsert, and then give it back to
him afterwards). Once you release the lock, you should stop touching
shared memory, period.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
