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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
