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
On Wed, Feb 16, 2011 at 7:06 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao masao.fu...@gmail.com
On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao masao.fu...@gmail.com wrote:
You suggest that the shared variable Stream tracks the WAL write
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao masao.fu...@gmail.com 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
On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao masao.fu...@gmail.com 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
On Sat, Feb 12, 2011 at 11:32 PM, Robert Haas robertmh...@gmail.com 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
On Sun, Jan 30, 2011 at 11:12 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes jeff.ja...@gmail.com 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
On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost sfr...@snowman.net 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
* 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 Sat, 2011-02-12 at 09:32 -0500, Robert Haas wrote:
On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost sfr...@snowman.net 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
On Mon, 2011-01-31 at 16:12 +0900, Fujii Masao wrote:
On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes jeff.ja...@gmail.com 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
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
On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost sfr...@snowman.net 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
On Fri, Feb 11, 2011 at 12:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost sfr...@snowman.net 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
* 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
On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes jeff.ja...@gmail.com 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
On Tue, Jan 25, 2011 at 6:38 PM, Fujii Masao masao.fu...@gmail.com 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
On Mon, Jan 24, 2011 at 11:25 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
So I'm thinking to change pg_last_xlog_receive_location not to
move
Thanks for the review!
On Wed, Jan 26, 2011 at 3:40 AM, Jeff Janes jeff.ja...@gmail.com 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
On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao masao.fu...@gmail.com 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
On Tue, Jan 25, 2011 at 4:25 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
So I'm thinking to change pg_last_xlog_receive_location not to
move
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
On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao masao.fu...@gmail.com 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
23 matches
Mail list logo
