On Mon, Oct 24, 2011 at 8:40 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Oct 21, 2011 at 12:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 20, 2011 at 9:51 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas robertmh...@gmail.com
On Fri, Oct 21, 2011 at 12:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 20, 2011 at 9:51 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas robertmh...@gmail.com wrote:
OK, so this is an artifact of the changes to make libpq communication
On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas robertmh...@gmail.com wrote:
OK, so this is an artifact of the changes to make libpq communication
bidirectional. But I'm still confused about where the error is coming
from. In your OP, you wrote In 9.2dev and 9.1, when walreceiver
detects an
On Thu, Oct 20, 2011 at 9:51 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas robertmh...@gmail.com wrote:
OK, so this is an artifact of the changes to make libpq communication
bidirectional. But I'm still confused about where the error is coming
from.
On Wed, Oct 19, 2011 at 11:28 AM, Robert Haas robertmh...@gmail.com wrote:
Convince me. :-)
Yeah, I try.
My reading of the situation is that you're talking about a problem
that will only occur if, while the master is in the process of
shutting down, a network error occurs.
No. This happens
On Wed, Oct 19, 2011 at 3:31 PM, Fujii Masao masao.fu...@gmail.com wrote:
(2) for this marginal improvement, you're giving up including
PQerrorMessage(streamConn) in the error message that ultimately gets
omitted, which seems like a substantial regression as far as
debuggability is concerned.
On Wed, Oct 19, 2011 at 2:31 AM, Fujii Masao masao.fu...@gmail.com wrote:
My reading of the situation is that you're talking about a problem
that will only occur if, while the master is in the process of
shutting down, a network error occurs.
No. This happens even if a network error doesn't
On Wed, Oct 19, 2011 at 9:44 PM, Robert Haas robertmh...@gmail.com wrote:
The original behavior, in 9.0, is that all outstanding WAL are
replicated to the standby when the master shuts down normally.
But ISTM the behavior was changed unexpectedly in 9.1. So
I think that it should be
On Wed, Oct 19, 2011 at 10:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 19, 2011 at 9:44 PM, Robert Haas robertmh...@gmail.com wrote:
The original behavior, in 9.0, is that all outstanding WAL are
replicated to the standby when the master shuts down normally.
But ISTM the
On Fri, Oct 14, 2011 at 7:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Oct 13, 2011 at 10:08 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 12, 2011 at 10:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao masao.fu...@gmail.com
On Thu, Oct 13, 2011 at 10:08 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 12, 2011 at 10:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2dev and 9.1, when walreceiver detects an error while sending data
On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2dev and 9.1, when walreceiver detects an error while sending data to
WAL stream, it always emits ERROR even if there are data available in the
receive buffer. This might lead to loss of transactions because such
On Wed, Oct 12, 2011 at 10:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2dev and 9.1, when walreceiver detects an error while sending data to
WAL stream, it always emits ERROR even if there are data available in
13 matches
Mail list logo
