On 5 December 2012 22:23, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Dec 5, 2012 at 4:15 PM, Tom Lane <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
