On Sun, Jul 17, 2011 at 10:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On Fri, Jul 15, 2011 at 6:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I'd say send the signal when wal buffers are more than X% full (maybe
>>> half). The suggestion to send it when wrapping around at the end of the
>>> array is not quite right, because that's an arbitrary condition that's
>>> not related to how much work there is for the walwriter to do. It
>>> should be cheap to check for this while advancing to a new wal buffer.
>
>> I think we need to put the calculation and SetLatch() after we release
>> WALInsertLock, so as to avoid adding contention.
>
> 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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
