Re: PITR potentially broken in 9.2

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Dec 5, 2012 at 4:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

regards, tom lane