On 5 December 2012 22:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Dec 5, 2012 at 4:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The argument for this is that although we might fetch a slightly stale
>>> value of the shared variable, it can't be very stale --- certainly no
>>> older than the spinlock acquisition near the bottom of the previous
>>> iteration of the loop. And this is a highly asynchronous feature
>>> anyhow, so fuzziness of plus or minus one WAL record in when the pause
>>> gets honored is not going to be detectable. Hence an extra spinlock
>>> acquisition is not worth the cost.
>
>> I wonder whether the cost of an extra spinlock acquire/release cycle
>> is really noticeable here. That can get expensive in a hurry when
>> lots of processes are contending the spinlock ... but I think that
>> shouldn't be the case here; most of the accesses will be coming from
>> the startup process. Of course atomic operations are much more
>> expensive than ordinary CPU instructions even under the best of
>> circumstances, but is that really material here? I'm just wondering
>> whether this is premature optimization that's going to potentially
>> bite us later in the form of subtle, hard-to-reproduce bugs.
>
> I have the same doubt about whether it's really significant. However,
> I think it's much more likely that we'd find out it is significant than
> that we'd find out anybody could detect the lack of a memory barrier
> there.
Agreed. And any future logic to stop at a specific point will be
exactly precise because the decision and action will be taken in same
process.
Patch looks good.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services