On 26.02.2011 16:58, Robert Haas wrote:
It sounds like the only thing we have definite agreement about from
all this is that apply_location should be renamed to replay_location
in pg_stat_replication, a point fairly incidental to the what this
patch is about. It seems fairly unsatisfying to just
On Wed, Feb 16, 2011 at 7:06 AM, Robert Haas wrote:
> On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao wrote:
>> On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas wrote:
>>> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote:
You suggest that the shared variable Stream tracks the WAL write locati
On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao wrote:
> On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas wrote:
>> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote:
>>> You suggest that the shared variable Stream tracks the WAL write location,
>>> after it's set to the replication starting positio
On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote:
>> You suggest that the shared variable Stream tracks the WAL write location,
>> after it's set to the replication starting position? I don't think
>> that the write
>> location needs to be
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote:
> You suggest that the shared variable Stream tracks the WAL write location,
> after it's set to the replication starting position? I don't think
> that the write
> location needs to be tracked in the shmem because other processes than
> walrece
On Sat, Feb 12, 2011 at 11:32 PM, Robert Haas wrote:
> So, what if we did some renaming? I'd be inclined to start by
> renaming "receivedUpTo" to Flush, and add a new position called
> Stream. When walreciever is started, we set Stream to the position at
> which streaming is going to begin (whic
On Sun, Jan 30, 2011 at 11:12 PM, Fujii Masao wrote:
> On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes wrote:
>> I do not understand what doing so gets us.
>>
>> Say we previously received 2/3 of a WAL file, and replayed most of it.
>> So now the shared buffers have data that has been synced to that
On Mon, 2011-01-31 at 16:12 +0900, Fujii Masao wrote:
> On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes wrote:
> > I do not understand what doing so gets us.
> >
> > Say we previously received 2/3 of a WAL file, and replayed most of it.
> > So now the shared buffers have data that has been synced to
On Sat, 2011-02-12 at 09:32 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> Actually... wait a minute. Now that I'm thinking about this a little
> >> more, I'm not so convinced. If we leave this the way is,
* Robert Haas (robertmh...@gmail.com) wrote:
> I think a big part of the problem here is that we have wildly
> inconsistent terminology for no especially good reason.
Agreed.
> Thoughts, comments?
I thought about this for a bit and agree w/ your suggestions.
So, +1 from me.
Thanks,
On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Actually... wait a minute. Now that I'm thinking about this a little
>> more, I'm not so convinced. If we leave this the way is, and just
>> paper over the problem using the method Stephen an
* Robert Haas (robertmh...@gmail.com) wrote:
> Actually... wait a minute. Now that I'm thinking about this a little
> more, I'm not so convinced. If we leave this the way is, and just
> paper over the problem using the method Stephen and I both had in
> mind, then we could be streaming from a pos
On Fri, Feb 11, 2011 at 12:25 PM, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost wrote:
>> Fujii, all,
>>
>> * Fujii Masao (masao.fu...@gmail.com) wrote:
>>> That logic exists because we'd like to check that newly-received WAL
>>> data is consistent with previous one by vali
On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost wrote:
> Fujii, all,
>
> * Fujii Masao (masao.fu...@gmail.com) wrote:
>> That logic exists because we'd like to check that newly-received WAL
>> data is consistent with previous one by validating the header of new
>> WAL file. So since we need the he
Fujii, all,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> That logic exists because we'd like to check that newly-received WAL
> data is consistent with previous one by validating the header of new
> WAL file. So since we need the header of new WAL file, we retreat the
> replication starting loca
On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes wrote:
> I do not understand what doing so gets us.
>
> Say we previously received 2/3 of a WAL file, and replayed most of it.
> So now the shared buffers have data that has been synced to that WAL
> file already, and some of those dirty shared buffers
On Tue, Jan 25, 2011 at 6:38 PM, Fujii Masao wrote:
>> The third seems more problematic. In the XLogPageRead,
>> it checks to see if more records have been received beyond what
>> has been applied. By using the non-retreating value here, it seems
>> like the xlog replay could start replaying re
Thanks for the review!
On Wed, Jan 26, 2011 at 3:40 AM, Jeff Janes wrote:
> I believe the new walrcv->receiveStart was introduced to divide up those
> behaviors that should go backwards from those that should not.
Yes.
> The non-retreating value is used in 3 places (via GetWalRcvWriteRecPtr)
>
On Mon, Jan 24, 2011 at 11:25 AM, Robert Haas wrote:
> On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao wrote:
>> On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
>>> So I'm thinking to change pg_last_xlog_receive_location not to
>>> move backwards.
>>
>> The attached patch does that.
>
> It look
On Tue, Jan 25, 2011 at 4:25 AM, Robert Haas wrote:
> On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao wrote:
>> On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
>>> So I'm thinking to change pg_last_xlog_receive_location not to
>>> move backwards.
>>
>> The attached patch does that.
>
> It looks
On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao wrote:
> On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
>> So I'm thinking to change pg_last_xlog_receive_location not to
>> move backwards.
>
> The attached patch does that.
It looks to me like this is changing more than just the return value
of
On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
> So I'm thinking to change pg_last_xlog_receive_location not to
> move backwards.
The attached patch does that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
receive_location_not_back_of
Hi,
In the case where there are multiple standbys, when a failover
happens, we usually calculate most advanced standby by using
pg_last_xlog_receive_location or pg_last_xlog_replay_location,
and promote it to new master. The problem is that neither
function might return the right last location of
23 matches
Mail list logo
