On Wed, 2010-03-31 at 23:54 +0300, Heikki Linnakangas wrote:
Robert Haas wrote:
Agreed. I think if the server starts up in standby mode and it is an
inconsistent state with no source of WAL, then the startup process
should exit with a suitable error message, which AIUI will result in
the
On Mon, Feb 15, 2010 at 3:45 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Feb 12, 2010 at 11:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Even more to the point is that some of them, like PGPORT, are highly
likely to be set in a server's environment to point to the server
itself. It
On Mon, Apr 5, 2010 at 4:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-03-31 at 23:54 +0300, Heikki Linnakangas wrote:
Robert Haas wrote:
Agreed. I think if the server starts up in standby mode and it is an
inconsistent state with no source of WAL, then the startup process
On Mon, 2010-04-05 at 07:11 -0400, Robert Haas wrote:
On Mon, Apr 5, 2010 at 4:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-03-31 at 23:54 +0300, Heikki Linnakangas wrote:
Robert Haas wrote:
Agreed. I think if the server starts up in standby mode and it is an
On Mon, Apr 5, 2010 at 7:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-04-05 at 07:11 -0400, Robert Haas wrote:
On Mon, Apr 5, 2010 at 4:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-03-31 at 23:54 +0300, Heikki Linnakangas wrote:
Robert Haas wrote:
Agreed.
On Mon, 2010-04-05 at 18:03 +0900, Fujii Masao wrote:
I'm leaning toward postponing the item to v9.1 or later.
If you want to defer anything, then I'd like to get a summary of what
you are thinking of deferring and why that is acceptable. Right now
there are lots of unfinished items and no
On Wed, Mar 31, 2010 at 1:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas robertmh...@gmail.com wrote:
I just tested this and it seems to just sit there doing this over and
over again:
LOG: record with zero length at 0/3006B28
I'm not sure that
Robert Haas wrote:
Agreed. I think if the server starts up in standby mode and it is an
inconsistent state with no source of WAL, then the startup process
should exit with a suitable error message, which AIUI will result in
the whole server shutting down. However if there is no source of WAL
On Wed, Mar 31, 2010 at 4:54 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
Agreed. I think if the server starts up in standby mode and it is an
inconsistent state with no source of WAL, then the startup process
should exit with a suitable error message,
Robert Haas wrote:
Is it reasonable to think that we can find a way to make it not print
the duplicate messages over and over again?
LOG: record with zero length at 0/3006B28
Maybe only print that if the location has advanced since the last such
message?
Yeah, seems reasonable.
On Wed, Mar 31, 2010 at 5:23 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
Is it reasonable to think that we can find a way to make it not print
the duplicate messages over and over again?
LOG: record with zero length at 0/3006B28
Maybe only print
On Thu, Apr 1, 2010 at 6:04 AM, Robert Haas robertmh...@gmail.com wrote:
I wouldn't recommend setting up a standby server like that, but it's not
totally unreasonable. So the standby always has a potential source of
WAL, pg_xlog.
OK.
OK, too. I turn down the patch.
Is it reasonable to
On Wed, Mar 31, 2010 at 9:01 PM, Fujii Masao masao.fu...@gmail.com wrote:
Agreed. But what log message is repeated depends on the situation.
So message without any location might be output. BTW, In my testing,
the following message was repeated.
LOG: invalid magic number in log file
On Tue, Mar 30, 2010 at 12:26 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 3, 2010 at 9:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao masao.fu...@gmail.com wrote:
If standby_mode is enabled, and neither primary_conninfo nor
On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas robertmh...@gmail.com wrote:
I just tested this and it seems to just sit there doing this over and
over again:
LOG: record with zero length at 0/3006B28
I'm not sure that we should forbid this configuration, but the current
behavior doesn't
On Wed, Mar 3, 2010 at 9:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao masao.fu...@gmail.com wrote:
If standby_mode is enabled, and neither primary_conninfo nor restore_command
are set, the standby would get stuck. How about forbidding (i.e.,
On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao masao.fu...@gmail.com wrote:
If standby_mode is enabled, and neither primary_conninfo nor restore_command
are set, the standby would get stuck. How about forbidding (i.e., causing a
FATAL message) this wrong setting?
Here is the patch which forbids
On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Joachim Wieland wrote:
On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the
On Fri, Feb 12, 2010 at 11:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Even more to the point is that some of them, like PGPORT, are highly
likely to be set in a server's environment to point to the server
itself. It would be extremely dangerous to automatically try to start
replication just
On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Agreed. I've changed it now so that if primary_conninfo is not set, it
doesn't try to establish a streaming connection. If you want to get the
connection information from environment variables, you
On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Agreed. I've changed it now so that if primary_conninfo is not set, it
doesn't try to establish a streaming connection. If you want to get the
connection information from environment variables, you
Joachim Wieland wrote:
On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Agreed. I've changed it now so that if primary_conninfo is not set, it
doesn't try to establish a streaming connection. If you want to get the
connection information from
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
There's yet another mode that would be useful with hot standby: start up
the standby, but don't poll the archive and don't try to connect to the
master. Kind of 'paused' mode. Simon had functions to do that and more
in the original
On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
But if we fail in restoring the archived WAL file, standby_mode =
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Joachim Wieland wrote:
If no primary_conninfo variable is set explicitly in the configuration
file, check the environment variables. If the environment variable is
not set, don't try to establish a connection.
The environment
On Wed, 2010-02-10 at 13:16 +0200, Heikki Linnakangas wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
The docs say If this parameter is
Simon Riggs wrote:
The docs say If this parameter is on, the streaming replication is
enabled. So who is wrong?
The docs.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
Fujii Masao wrote:
On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep
On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the another connection settings (environment variables
or defaults). This is intentional behavior, and would make the setup of
Fujii Masao wrote:
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
But if we fail in restoring the archived WAL file, standby_mode = on
*always* tries to start streaming replication.
Hmm, somehow I thought it doesn't if you
Fujii Masao wrote:
On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
But if we fail in restoring the archived WAL
Joachim Wieland wrote:
On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the another connection settings (environment variables
or defaults). This is intentional behavior, and
We want to teach people that Hot Standby and Streaming Replication are
two different features. However, Streaming Replication calls its main
parameter standby_mode which reminds more of Hot Standby than of
Streaming Replication.
People could also run a warm standby without streaming replication,
Joachim Wieland wrote:
We want to teach people that Hot Standby and Streaming Replication are
two different features.
I'm not sure about that, actually. Now that they're both in the tree,
they work nicely together and many users will think of them as one.
However, Streaming Replication calls
On Wed, Feb 10, 2010 at 12:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
37 matches
Mail list logo
