From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: PITR potentially broken in 9.2 |
Date: | 2012-12-05 23:37:03 |
Message-ID: | CA+U5nMJpRieD1mk9M64ZAx9gGUk=XE4rrMEgyRgjYshTmv7h9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 5 December 2012 22:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-12-05 23:55:30 | Re: PITR potentially broken in 9.2 |
Previous Message | Tom Lane | 2012-12-05 23:35:47 | Re: PITR potentially broken in 9.2 |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2012-12-05 23:37:23 | Functional dependency in GROUP BY through JOINs |
Previous Message | Tom Lane | 2012-12-05 23:35:47 | Re: PITR potentially broken in 9.2 |