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 move
On Mon, Apr 5, 2010 at 7:34 AM, Simon Riggs wrote:
> On Mon, 2010-04-05 at 07:11 -0400, Robert Haas wrote:
>> On Mon, Apr 5, 2010 at 4:46 AM, Simon Riggs wrote:
>> > On Wed, 2010-03-31 at 23:54 +0300, Heikki Linnakangas wrote:
>> >> Robert Haas wrote:
>> >> > Agreed. I think if the server starts
On Mon, 2010-04-05 at 07:11 -0400, Robert Haas wrote:
> On Mon, Apr 5, 2010 at 4:46 AM, Simon Riggs 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
On Mon, Apr 5, 2010 at 4:46 AM, Simon Riggs 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
>> > should exi
On Mon, Feb 15, 2010 at 3:45 PM, Fujii Masao wrote:
> On Fri, Feb 12, 2010 at 11:46 PM, Tom Lane 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 autom
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
On Wed, Mar 31, 2010 at 9:01 PM, Fujii Masao 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 0, segment 14, of
On Thu, Apr 1, 2010 at 6:04 AM, Robert Haas 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 think that we can
On Wed, Mar 31, 2010 at 5:23 PM, Heikki Linnakangas
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 that if the location has a
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 4:54 PM, 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
>>
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
On Wed, Mar 31, 2010 at 1:47 AM, Fujii Masao wrote:
> On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas 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 configu
On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas 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 seem right either.
On Tue, Mar 30, 2010 at 12:26 AM, Fujii Masao wrote:
> On Wed, Mar 3, 2010 at 9:41 PM, Fujii Masao wrote:
>> On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao wrote:
>>> If standby_mode is enabled, and neither primary_conninfo nor restore_command
>>> are set, the standby would get stuck. How about fo
On Wed, Mar 3, 2010 at 9:41 PM, Fujii Masao wrote:
> On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao 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 sett
On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao 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 that wrong setting
On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas
wrote:
> Joachim Wieland wrote:
>> On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao wrote:
>>> Yeah, even if primary_conninfo is not given, the standby tries to invoke
>>> walreceiver by using the another connection settings (environment variables
>
On Fri, Feb 12, 2010 at 11:46 PM, Tom Lane 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 because we find t
Heikki Linnakangas 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 variables in question are the l
On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
>> wrote:
>>> Fujii Masao wrote:
But if we fail in restoring the archived WAL file, "standby_mode = on"
*always* tries to start streaming replication.
>
Heikki Linnakangas 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 hot standby patch.
And having
Joachim Wieland wrote:
> On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
> 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 can u
On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
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 can use
> primary_conninfo=''.
Why
On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas
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 can use
> primary_conninfo=''.
OK,
Joachim Wieland wrote:
> On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao 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
Fujii Masao wrote:
> On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas
> wrote:
>> Fujii Masao wrote:
>>> On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
>>> wrote:
Fujii Masao wrote:
> But if we fail in restoring the archived WAL file, "standby_mode = on"
> *always* tries to s
Fujii Masao wrote:
> On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
> 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 don't set primary_connin
On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao 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 SR
> easier. So I'd
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Wed, Feb 10, 2010 at 8:16 PM, 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'
Fujii Masao wrote:
> On Wed, Feb 10, 2010 at 8:16 PM, 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.
>
> But i
On Wed, Feb 10, 2010 at 8:16 PM, 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.
But if we fail in restoring the arc
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 sub
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 i
On Wed, Feb 10, 2010 at 12:16 PM, 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.
>
> If you want to use pg_standby o
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 call
36 matches
Mail list logo
