Re: Function to know last log write timestamp

On Wed, Nov 26, 2014 at 4:05 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Aug 15, 2014 at 8:17 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>>>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>>> > On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>>>> >> That's about the idea. However, what you've got there is actually
>>>> >> unsafe, because shmem->counter++ is not an atomic operation. It reads
>>>> >> the counter (possibly even as two separate 4-byte loads if the counter
>>>> >> is an 8-byte value), increments it inside the CPU, and then writes the
>>>> >> resulting value back to memory. If two backends do this concurrently,
>>>> >> one of the updates might be lost.
>>>> >
>>>> > All these are only written by one backend, so it should be safe. Note
>>>> > that that coding pattern, just without memory barriers, is all over
>>>> > pgstat.c
>>>>
>>>> Ah, OK. If there's a separate slot for each backend, I agree that it's safe.
>>>>
>>>> We should probably add barriers to pgstat.c, too.
>>>
>>> Yea, definitely. I think this is rather borked on "weaker"
>>> architectures. It's just that the consequences of an out of date/torn
>>> value are rather low, so it's unlikely to be noticed.
>>>
>>> Imo we should encapsulate the changecount modifications/checks somehow
>>> instead of repeating the barriers, Asserts, comments et al everywhere.
>>
>> So what about applying the attached patch first, which adds the macros
>> to load and store the changecount with the memory barries, and changes
>> pgstat.c use them. Maybe this patch needs to be back-patch to at least 9.4?
>>
>> After applying the patch, I will rebase the pg_last_xact_insert_timestamp
>> patch and post it again.
> Hm, what's the status on this patch? The addition of those macros to
> control count increment with a memory barrier seems like a good thing
> at least.

Thanks for reminding me of that! Barring any objection, I will commit it.

> The 2nd patch has not been rebased but still..

The feature that this 2nd patch implements is very similar to a part of
what the committs patch does, i.e., tracking the timestamps of the committed
transactions. If the committs patch will have been committed, basically
I'd like to no longer work on the 2nd patch to avoid the duplicate work.
OTOH, I'm concerned about the performance impact by the committs patch.
So, for the simple use case like the check of replication lag, what the 2nd
patch implements seems to be better, though...

Regards,

--
Fujii Masao