On Fri, Nov 28, 2014 at 9:07 PM, Fujii Masao wrote:
> On Wed, Nov 26, 2014 at 4:05 PM, Michael Paquier
> wrote:
>> On Fri, Aug 15, 2014 at 8:17 PM, Fujii Masao wrote:
>>> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund
>>> wrote:
On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
> On Th
On Wed, Nov 26, 2014 at 4:05 PM, Michael Paquier
wrote:
> On Fri, Aug 15, 2014 at 8:17 PM, Fujii Masao wrote:
>> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund
>> wrote:
>>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
wrote:
>
On Fri, Aug 15, 2014 at 8:17 PM, Fujii Masao wrote:
> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
>>> wrote:
>>> > On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>>> >> That's abou
On Thu, Aug 28, 2014 at 3:34 AM, Fujii Masao wrote:
> Theoretically it's not safe without a barrier on a machine with weak
> memory ordering. No?
Why not?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-
On Thu, Aug 28, 2014 at 2:44 AM, Jim Nasby wrote:
> On 8/27/14, 7:33 AM, Fujii Masao wrote:
>>
>> On Tue, Aug 19, 2014 at 1:07 AM, Robert Haas
>> wrote:
>>>
>>> On Fri, Aug 15, 2014 at 7:17 AM, Fujii Masao
>>> wrote:
On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund
wrote:
>
>>>
On 8/27/14, 7:33 AM, Fujii Masao wrote:
On Tue, Aug 19, 2014 at 1:07 AM, Robert Haas wrote:
On Fri, Aug 15, 2014 at 7:17 AM, Fujii Masao wrote:
On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
On Thu, Aug 14, 2014 at 2:21 PM, Andres Fre
On Tue, Aug 19, 2014 at 1:07 AM, Robert Haas wrote:
> On Fri, Aug 15, 2014 at 7:17 AM, Fujii Masao wrote:
>> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund
>> wrote:
>>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
wrote:
> On
On Fri, Aug 15, 2014 at 7:17 AM, Fujii Masao wrote:
> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
>>> wrote:
>>> > On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>>> >> That's abou
On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
>> 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
>> >>
On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund 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
On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund wrote:
> On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>> On Thu, Aug 14, 2014 at 1:51 PM, Fujii Masao wrote:
>> > On Fri, Aug 15, 2014 at 1:55 AM, Robert Haas wrote:
>> >> On Mon, Aug 11, 2014 at 3:20 AM, Fujii Masao
>> >> wrote:
>> >>> There
On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
> On Thu, Aug 14, 2014 at 1:51 PM, Fujii Masao wrote:
> > On Fri, Aug 15, 2014 at 1:55 AM, Robert Haas wrote:
> >> On Mon, Aug 11, 2014 at 3:20 AM, Fujii Masao wrote:
> >>> There is no extra spinlock.
> >>
> >> The version I reviewed had one; that
On Thu, Aug 14, 2014 at 1:51 PM, Fujii Masao wrote:
> On Fri, Aug 15, 2014 at 1:55 AM, Robert Haas wrote:
>> On Mon, Aug 11, 2014 at 3:20 AM, Fujii Masao wrote:
>>> There is no extra spinlock.
>>
>> The version I reviewed had one; that's what I was objecting to.
>
> Sorry for confusing you. I po
On Fri, Aug 15, 2014 at 1:55 AM, Robert Haas wrote:
> On Mon, Aug 11, 2014 at 3:20 AM, Fujii Masao wrote:
>> There is no extra spinlock.
>
> The version I reviewed had one; that's what I was objecting to.
Sorry for confusing you. I posted the latest patch to other thread.
This version doesn't us
On Mon, Aug 11, 2014 at 3:20 AM, Fujii Masao wrote:
> There is no extra spinlock.
The version I reviewed had one; that's what I was objecting to.
Might need to add some pg_read_barrier() and pg_write_barrier() calls,
since we have those now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On 2014-08-11 16:20:41 +0900, Fujii Masao wrote:
> On Mon, Aug 11, 2014 at 3:54 PM, Andres Freund wrote:
> > On 2014-08-11 12:42:06 +0900, Fujii Masao wrote:
> >> On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii
> >> wrote:
> >> >> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii
> >> >> wrote:
> >
On Mon, Aug 11, 2014 at 3:54 PM, Andres Freund wrote:
> On 2014-08-11 12:42:06 +0900, Fujii Masao wrote:
>> On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii wrote:
>> >> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii
>> >> wrote:
>> >>> We can know the LSN of last committed WAL record on primary b
On 2014-08-11 12:42:06 +0900, Fujii Masao wrote:
> On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii wrote:
> >> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
> >>> We can know the LSN of last committed WAL record on primary by using
> >>> pg_current_xlog_location(). It seems there's no API t
On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii wrote:
>> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
>>> We can know the LSN of last committed WAL record on primary by using
>>> pg_current_xlog_location(). It seems there's no API to know the time
>>> when the WAL record was created. I wo
> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
>> We can know the LSN of last committed WAL record on primary by using
>> pg_current_xlog_location(). It seems there's no API to know the time
>> when the WAL record was created. I would like to know standby delay by
>> using pg_last_xact_rep
On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
> We can know the LSN of last committed WAL record on primary by using
> pg_current_xlog_location(). It seems there's no API to know the time
> when the WAL record was created. I would like to know standby delay by
> using pg_last_xact_replay_ti
We can know the LSN of last committed WAL record on primary by using
pg_current_xlog_location(). It seems there's no API to know the time
when the WAL record was created. I would like to know standby delay by
using pg_last_xact_replay_timestamp() and such that API.
If there's no such a API, it wou
22 matches
Mail list logo